Ok, to be clear, you should NOT do this as a site developer, but if you need to work with a site that behaves this way, my answer is designed to say what CAN be done safely. Basically you can't trust anything on the page itself, all you can trust is that if the SSL cert resolves, then the post is talking to the legitimate server for the URL that it claims to be. You have to manually validate that it is sending to that URL and that it is the appropriate URL. This can only be done if the response is going to the same top level URL that served the page since you know you are trying to connect to that top level domain.
As long as the user was verifying that the post target was the intended server and that post connection was HTTPS and that there was no scripts that could alter the content present on the page and the browser doesn't send over an HTTPS link that doesn't have a valid cert for the URL being sent to, then the form would be perfectly secure. Note that you could only know the intended server if it is posting to the same TLD as the page is hosted from. You wouldn't, for example, know if www.bob.com telling you to submit the form to www.bobspayments.com was valid. It is also possible that if the same information submitted to two different services would do different things, then a malicious user might be able to make use of that. The problem is that a user won't do that. It does protect against passive sniffing, but won't provide verification to the user that the site is legit which SHOULD (but probably won't in many cases) raise concern by the user.
An active MITM attacker could simply change the page to return the information to them, but then again, this could be done even if the page itself was HTTPS since many users wouldn't notice if it was actually an HTTP page that was returned, so I'm not sure if there is really a significantly larger threat from an active MITM either since in either case.
The real problem would be the user experience and the fact that it shows up to the user as the page not being secured, so HTTPS is still preferable for the entire page for that reason. To clarify, there is a lot that can go wrong if the page contents are not authentic, so proving authenticity is preferable, but as long as information is actually submitted over SSL, then it will be protected. The problem is guaranteeing that it will be without manually reviewing page code.