As a commenter mentioned above, the weak point here is the fact that you only enforce HTTPS after the user has logged in. Since your login page is served insecurely, an active attacker could modify it to steal passwords. A well known tool to do this is SSLStrip: http://www.thoughtcrime.org/software/sslstrip/
Thanks for the example. Looks like we'll give up attempting to serve any HTTP pages in the future, and do as you recommend -- I don't see any way of getting around the login-form-phishing hack you describe.
The Tunisian government recently took advantage of Facebook's insecure login page to steal passwords for _everyone in the country_: http://blog.jgc.org/2011/01/code-injected-to-steal-passwords...
Protocol-relative URLs may be useful while migrating to HTTPS, but should not be needed long-term. All content should only be served securely.
Once a site is fully functional over HTTPS, adding the HSTS header is an important last step to further mitigate active attacks. http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security