Entering sensitive information into non-SSL site that uses secure iFrame

I'm wondering what are the security risks of this type of setup for the users.

It's almost as bad as serving everything over plain HTTP.

You get protection against purely passive listening attacks, but really anyone in the position to do that kind of man-in-the-middle attack is very likely also to be able to do an active attack, changing the content that gets sent back to the browser. That could include changing the iframe src in the unprotected parent page, or injecting some attack script.

In practice the HTTPS-iframe gets you protection from a casual attacker sniffing general traffic, but for any man-in-the-middle targeting the site specifically it is trivial to make the measure ineffective.

It's up to the provider whether they think this barely-more-than-plain-HTTP assurance is suitable for the kind of information that will be entered into the frame - except if that information contains credit card data, in which case they have an obligation to abide by the PCI-DSS rules requiring HTTPS. (Assessors are expected to verify that HTTPS indicators are visible in the browser chrome.)

seeing the browser's address bar unable to provide identity/encryption information is disconcerting.

Yes - independently of the question of actual security, this is poor perceived-security and may put some users off.

Without viewing the source of the page, how do I know where the iframe content is from?

Quite. Viewing source/DOM isn't something you can expect an average user to do.

Additionally, even if you verify the iframe is being served using HTTPS, there is nothing stopping the unsecured parent page from interfering with it with 'clickjacking' attacks, for example a keylogging overlay form.

Is relying on the godaddy seal sufficient?

Seals offer no security, as they are trivially spoof-able. They are nothing but a marketing exercise; CAs should be ashamed of this deliberately misleading behaviour.