Is it a bad idea to load an OpenID provider into an iframe if the provider and RP are on the same domain?

There are a lot of questions here where someone wants to load an OpenID login page in an iframe rather than a redirect, and the provider controls the entire appearance of the login page. For very solid security reasons (anti-phishing in the first place) this is a big no-no, forbidden, and most OpenID providers refuse to load in an iframe.

I was presented with a situation where OpenID is used within a single set of websites and applications. The OpenID provider has a whitelisted RP and will only respond to these RPs. There is a desire to tweak the provider's login page intensively based on which RP sent the user to it. (If there are serious arguments to defend against this, I would like to know about them as well.)

The suggested solution is to simply let the RPs present the login page in an iframe so they can put any design in the login box they want. In this scenario, the Provider will only host the "Username" "Password" and "Login" "Forgot password" "Register a new account" fields in the Provider, the rest of the page will be in the RP and still have the RP address in the title bar. Not optimal, yes, but the argument is that "this is a different subdomain, but the same 2nd level domain, so it's still okay."

I don't understand how this could be so - very different login pages for different applications still leave users more vurnerable for phishing and other attacks. Am I wrong in this conclusion? Every SO question about this seems to be about using an external or public provider, and the counter-argument I come across is that these issues don't apply to a private provider limited to sites on the same domain.