SNI, like wildcard and SAN certificates, allows you to have multiple SSL sites with the same IP (same VIP). SNI is somewhat different though because it's actually an extension to the TLS protocol that, when supported, allows the server to "switch" the server certificate it presents based on what the client is asking for. Essentially, in the client's SSL CLIENTHELLO message, the client would normally say "hello, I'd like to talk SSL, and these are the ciphers I support". With SNI, the client says, "hello, I'd like to talk SSL, and this is the hostname I'd like to talk to, and here are the ciphers I support". Most modern browsers now support SNI, though you should still consider what your client base may be. To enable SNI, create a separate client SSL profile for each hostname and enter that name into the Server Name block of the profile. Also select one of the profiles to be the default should the user access with an IP or not support SNI. Apply all of these client SSL profiles to the virtual server. SNI requires v11, but that's all it takes to configure.
As for selecting SSL profile via URL, that depends on if you mean hostname or URI. If by hostname then the above methods should work. If by URI, then your master VIP is potentially a good idea. You'd need two VIPs: the master VIP that clients should know and redirects based on that original URI path, and the application VIP that has the SNI (or wildcard/SAN) client SSL profiles. You cannot do URI-based load balancing until after you've negotiated the SSL session.