Strict Transport Security was designed to solve that problem partially by telling the browser to never make an insecure HTTP request:
http://caniuse.com/#feat=stricttransportsecurity
That's widely supported now but it does require your browser to have previously visited the legitimate site within the stored `max-age` period. Preloading (https://hstspreload.appspot.com/) can close that further but increases the organizational commitment that your web developers will never break the all-HTTPS contract by mistake.
Providing an HTTPS login with an otherwise HTTP site is vulnerable to redirection to HTTP or to another site.
There is lots of evidence that suggests that in this configuration, cookies are often not set up properly (secure only) and can therefore be transmitted and stolen over HTTP.
This is what I meant, this is why I used "may". Obviously the user must know the details of how ssl works which is not many of them.
And if SSL is offered perhaps it should still be possible to access non-security-critical pages by plain old HTTP.
However, I'm not sure if this will open attack vectors for the unencrypted sites. I.e. I'd imagine that a man-in-the-middle-style attack could show the main site / URL (www.mydomain.tld) with another cert and just forward the un{encrypted,secure} content … but then again, this is not a new technique and can be prevented by public key pinning (though, https://news.ycombinator.com/item?id=12434585 :-/), DNSSEC/DANE (no browser vendor buy-in yet), etc.
Any idea if this were a sane idea for other sites as well? With enough momentum, browser vendors could detect and display un{encrypted,unsecure}. sub-domains specially.