I don't think any of the other answers covers the whole story:
What you want to do is possible for a server to do, because of SNI. However, nginx, even though it supports SNI, does not support doing what you want to do. nginx will react to an unmatched SNI name by treating the request as if it's for your default SSL site (and if you have marked no SSL site as your default, the first SSL site in its configuration). This will usually result in the user seeing a certificate warning notice, because the name on the certificate nginx sends doesn't match the name the client requested.
The RFC for SNI specifies that the server MAY consider an unrecognized SNI name as fatal:
If the server understood the client hello extension but does not
recognize the server name, it SHOULD send an "unrecognized_name"
alert (which MAY be fatal).
As far as I can tell, however, both Apache and nginx proceed with the connection and treat it in the same way as they would treat an unmatched or missing "Host:" header, which is to select the virtual host marked as default for that address:port.
Unless you have acquired an SSL certificate matching every possible domain name the client may use when contacting your server, it is not possible to prevent the user seeing a warning about an invalid certificate before proceeding. Even if you do a redirect as soon as they come to the site, this will be processed only after the invalid certificate is accepted.
2017 update: since it's easy to get free SSL certificates for all your domains now, you could get SSL certs for all your domains, even if you don't intend to serve actual content though HTTPS on them, just to ensure that any redirects or error messages will work without any warning about mismatched certificates.