Sending HTTP on HTTPS dedicated port is not expected normally, though possible. In practice, production is running on 80 and 443 ports, so that is not really an issue unless somebody is sort of "hacking". In case different ports are used (eg. default Tomcat's) then the problem might arise just because people will forget to type "https" in front of URL.
In any case standard behavior is to return
HTTP 400 Bad Request. This is done eg. by Apache web server.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>400 Bad Request</title>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
Tomcat TLS/SSL HTTP connector doesn't do this obviously, and I suspect that it replies with some TLS handshake error message (discussed partially here http://stackoverflow.com/questions/7164944/unexpected-results-when-attempting-to-access-tomcat-6-https-connector-using-http).
In production, SSL is usually terminated on reverse proxy server (such as Apache) which handles even such a bad request gracefully (as described above).