I think you can do this, but not the way you're trying to do it.
An SSL certificate is a statement binding a public encryption key to an X.500 structure which includes a CN, or Common Name, element; a signed certificate is one such where the binding is verifiably certified by a third-party certification authority, using the a public key already known to end-users (that stack of Certification Authority (CA) certificates living inside your browser).
When you visit an SSL-secured web site with a browser, the signed CN is made known to the browser. What the browser chooses to do with it is up to the browser. The browsers I'm aware of compare it to the host name requested, and error if it's different (or if that certified binding doesn't stand up to analysis, eg the signing certificate is not known to the browser or the binding is out-of-date, but that's a different issue). There's nothing that in principle stops you from getting a publicly-signed certificate where the CN is an IP address not a FQDN (fully-qualified domain name) [1], but that won't magically make the browser compare the CN with the IP address, instead of with the requested hostname.
I suspect the simplest way to solve your problem is to start your own CA, which is easy to do, and there are many public tutorials about; one is here. Once your end-users import your CA into their browsers, all certificates you mint will be accepted as authoritative.
You may then have a second problem in that you want to run a lot of NameVirtualHost sites on a single IP address. This has historically been insuperable, since (unlike TLS) SSL negotiation happens before anything else on a connection; that is, the CN embedded in your certificate is made known to, and used by, the client before the client is able to say what host they're trying to connect to.
Recently, a protocol extension called SNI (Server Name Indication) seems to have been introduced, which allows client and server to indicate that they'd like to do some host name stuff before the SSL certificate is presented, allowing the right one of a set of certificates to be given by the server. Apparently this requires apache 2.2.10, a sufficiently recent version of OpenSSL, and (importantly) client-side support.
So if I had to do what you're trying to do, I'd be looking at minting my own CA certificate, telling my end-users that they have to use browsers that support SNI and import my CA root certificate, and cutting and signing my own SSL certificates for each bugtrack site.
[1] OK, you may not have found anyone who'll do it, but that's an implementation detail. What I'm trying to show here is that even if you did, it wouldn't solve your problem.
Best Answer
With bog-standard SSL, this is fine. HA provides the old certificate, validly-signed, and clients using the old A record from the DNS and connecting to that server will continue to accept it. HB will provide the new certificate, and clients getting the new A record will connect to it and accept the new certificate. They can peacefully co-exist.
That said, there are some extensions to SSL that may make this more tricky. Browser plugins like Certificate Patrol, which cache SSL certificates, will flag up the change, and if the client is unlucky enough to get the old record after having validated the new one (perhaps a user will move a laptop from work (old DNS) to a cybercafe (new DNS), then back to work), the plugin will grumble.
I have a recollection of another distributed system that allowed multiple users to avoid MITM certification attacks by pooling the many client views of the certificate seen at any given server. Whilst I can't find a reference to it right now, this would most definitely cause problems with your scenario.
But these aren't hugely common yet, so you'll probably be OK.