why it doesn't work and how to fake it
Quite often I'm answering the same question: Customers want to make sure that secret data always gets transmitted through https, while they fear the encryption burden of forcing https everywhere. I need a point to refer to for the future - congratulations, you found this point.
This story has several different aspects. First, let me start with the underlying assumption:
Mixing http and https does! not! work!™
Now that this is out of the way, let me get to other arguments:
If you're having somewhat current hardware on your webserver, encryption doesn't impose a huge burden any more when configured sensibly. Yes, there's some more overhead than going unencrypted, but when you need encryption for some data, you probably don't want to do it partially, but correctly. If you don't have experience setting up https, get help from somebody who does (e.g.). Your biggest problem is not how to set up a well performing https endpoint: Your biggest problem is to set it up correctly.
Your (by order of magnitude) second biggest problem is to set up the performance. And if you had experienced help in setting it up correctly, the odds are that performance has been taken care of already. If not, your helping hand was most likely not very experienced. And if you can't affort to pay a helping hand I ask you to first measure your performance unter https before you complain about it being too low. Next, compare it to the odds that someone would get hold of your credentials, abuse your server and how long it would take to bring it back. Add this recovery time to the time that you save by hosting in http/https mixed mode
There's a great standard, and depending on the time you read this, it's implemented by most browsers (for IE it's expected in version 12...). The name is HSTS or RFC 6797. By sending a little header, it instructs a browser to only ever contact the given site through https, never through http. It also gives a timespan for its validity - typically at least a year and only test installations have it shorter.
You can (ab)use this standard for a poor-man's mixed-mode implementation. Note that I don't state that this is the solution, it's just a way to implement a mixed mode a bit more safely than without this setup.
In general, enabling HSTS is easy. On Apache, just unconditionally redirect all http traffic to https. On the https virtual server, add the following line to your configuration:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
The workaround: Enabling mixed mode
For Mixed-mode you omit the unconditional forwarding to https (naturally) and for the HSTS header you just go one level deeper in your stack: Move the header generation to your application server or application: The application server is supposed to forward login requests and login forms to https and - if necessary - generate new session cookies that never have been used through http. Then, whenever you actually log in: add the HSTS header. This forces the browser for anybody logging in to the site to choose HSTS, while allowing others to freely use http or https - to their choice.
Yes, this targets the browser, not the user. But in large they're sufficiently synonymous as everybody carries their own browser in their own pocket. And if anybody demands to configure mixed mode rather than https only, this is a good workaround for you to sleep reasonably well without too much of an argument on why mixed-mode does not work.
Now if only every browser would support HSTS...