Actually it is, because you'd still have a domain pointed to an IP address listening on 443, and that IP address wouldn't know how to handle the domain that is not configured to listen on 443, so it would serve the default domain (generally the first SSL-configured domain with Apache, or 'default_server' on Nginx). This means you'll be serving a certificate for your default site 'foo.com' when you requested 'bar.org', providing the user with a domain mismatch security warning.
The second non-solution would be to configure every domain with self-signed certificates, but then you'd still be sending your clients an untrusted certificate. The only way to truly provide SSL on a shared host is to configure it with a UCC certificate that includes every domain you are pointing at it, or generate cheap/free certificates like StartSSL's for every unique domain and subdomain you listen for.
Why does that matter if bar.org doesn't and isn't supposed to support HTTPS, and if there are no links to bar.org via HTTPS? In either scenario if someone manually types in https:// bar.org it's not going to work.
I don't think it's at all obvious or universally true that it's better to get an 'Unable to connect' error message than a certificate warning (btw, the default site could tell the user they arrived there by accident should they continue past the warning). Depends on the context.
I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.
People wouldn't be connecting to the website using HTTPS if it didn't have a certificate in the first place, so why does it matter if 'bar.org' doesn't have a certificate?
