You can definitely use the alternate, nothing stopping you from using the first example, you won't be penalized directly unless you try to canonical alternate a http area that defaults to SSL normally, causing obvious errors. I have nothing to cite this besides this is what
rel="alternate" is for; whether or not services support then trigger stuff is up to the service.
However, you will lose out on ranking signal due to not enforcing strong encryption everywhere. Besides that reason, in my opinion you should encrypt pages of generality too. Visitors now prefer [and they deserve] to be protected on the whole realm. It's turning into a conversion factor very quickly, and soon it will be the norm to see a green lock. Chrome Canary branch is a telling sign too. As of Nov 2015, there is an opt-in Chrome flag showing an insecure icon (similar to the busted red lock) when visiting normal http pages, anywhere on any site. I estimate, expect this to come to Chrome stable in about 10-12 months. Chrome stable has a massive chunk of userbase, and a surprising sum of the canary flags have come to life through its branch into stable.
Your server will be fine, encrypt everything! If you are worried about lag/speed/cost/etc, there are helpers around -- Cloudflare comes to mind first due to the free plan, cached all (varnish-ish), SPDY/HSTS/DNSSEC/Strong-Cipher, various other securities and pool size. It could help off-load some of the hurdle VS liability.