Before I get started, I need to mention that everything you are about to read is really just a starting point at best. It's all so much blather until you actually have something worth looking at and measuring to find the real performance characteristics of your system under a given load. As they say, measure twice, cut (spend/build) once.
That out of the way, I noticed four things. The first is this quote:
and a few other minor VMs for smaller tasks
I would consolidate those down to 1 "utility" VM. This will save on OS overhead for your system. RAM sharing in VMware for this kind of thing is good, but not perfect. If nothing else, you'll save some management overhead.
Second, load balancing within a single physical host is a little weird... with just the one host I think a single virtual machine with the same resources you would have used for three smaller ones is more appropriate. This is my opinion, though, and I suspect others may disagree.
What I'd really like to see you shoot for here is at least two, and better with three to five, physical hosts. The machines should be provisioned such that you have just enough horsepower in total to still run the VMs necessary to keep your system alive should one physical box fail entirely. That's when load balancing is really nice, because you've now set yourself up to combine your performance load balancing with the core of a high availability infrastructure. Unfortunately, it sounds like you already made a purchase here that might be more than you would need in any one system for this setup. But as an example of what I'd like to see you shoot for:
HOST1 HOST2 HOST3
----- ------ -------
DjangoApp1 DjangoApp2 DjangoApp3
DB1 DB2 Celery/RabitMQ1
Celery/RabbitMQ2 (warm-idle) UtilityServer2 (warm-idle) UtilityServer1
The above system allows you to continue to run with minimal work if any single physical host fails. This setup is still pretty simple, though. As you get larger your DB servers will eventually want their own physical hosts, you'll want HAProxy in the mix somewhere to handle balancing, a SAN (or two) somewhere in back for storage, and maybe a caching server (or pair or more) somewhere as well. But that's something you can build towards after the initial product is up and running.
Next up, 4GB is actually quite a lot of RAM for the utility server and Celery/RabbitMQ instances. You can likely get by with less than 1/2 that for those boxes, and 4GB could even be a little overboard for django, depending on what your actual load turns out to be. This frees up RAM for your database servers, which are often hungry for any RAM you can spare for them.
Finally, I'd like to hear your definition of "plenty of storage". If you just dropped a 2TB hard drive in there, or even a set of 4 in RAID 10, you might find it's not the size that matters here as much as it is the speed. Your database, especially, will eat up your I/O performance. Make sure you're handling this well, as it's easy to get wrong. If you're using a SAN, that's fine... but if not, for the example above at a minimum each of the physical hosts should be a 2U box with a minimum of 7 traditional disks for RAID 10 that includes a hot spare to start rebuilding right away when a disk fails, or a 1U box with 4 high-end SSDs (RAID 10 again). You might even want more on the systems supporting your database servers.
