To answer the specific question as asked, there actually is a proposal for something pretty much what you want, namely the HTTP Alternative Services proposed standard from the HTTP Working Group. It was published in its current form just a few months ago, on May 3 2016, and the current Internet-Draft expires November 4 2016.
Given how new it is, I expect UA support to be extremely spotty at best. (Mark Nottingham claims that support has been added to Firefox and Chrome, but doesn't give any version numbers.) Also, it's meant for the UA to interpret, not necessarily for the user to make a choice.
On a more general level, I think you have to consider why you don't want to "force" the UA to use HTTPS. Is it because of the performance cost of HTTPS? (Hint: that's completely negligible these days, especially if you are also able to implement HTTP/2.) Is it because some clients may be unable to use encryption? (Hint: if this is really, truly, a big use case for you, then support the unencrypted TLS cipher suites. I don't recommend that, but it is technically possible in much the same way as driving your car off a cliff is technically possible. At least that way, you should get HTTPS' authenticity guarantees, though not confidentiality.) Is it because you have clients that don't speak SNI? (Then consider allocating an IP address to that all-important web site to support the clients stuck on web browsers 5-10 years out of date.)
Forcing HTTPS has several very real benefits even if you don't have anything "secret" on the site or care about the small Google rank boost.
You can always use a HTTP 307 response to temporarily redirect the client from the HTTP site to the HTTPS site if you want to, but it somewhat defeats the point to combine a temporary redirect to HTTPS with HSTS.
Given that you are already using HSTS, I'd say just set up a HTTP 301 permanent redirection from the HTTP vhost to the HTTPS vhost and call it a day. There is very little reason not to these days.