I'm not sure how to determine the growth per VM in the datastore but did have a couple other things come to mind. First you said the datastore was 3.5TB and had 30 VMs. How much of the 3.5TB is the VMs themselves? I'm just wondering what the average VM size is.
Also do you know if any of the VMs are swaping to disk? That is, what is the memory utilization on your ESX hosts like?
Keith brings up some really key questions that make me wonder if there may be a better way to optimize your use of the storage. So from what has been said so far, I understand it that you have a 3.5TB single-datastore backed by a roughly 10.5TB volume. That is 3.5TB + (datastore size * 2 for snapshot reserve) = ~10.5TB volume.
So dedupe has some limitations based on the controller model you are using and the version of DOT you are running. I would look to be sure that your config is not exceeding any limitations.
Secondly, dedupe for virtual environments is typically best acheived where lots of the same OS, and only the OS disks, is stored on the same datastore. While it sounds like you may in fact have that going for you here, you are also mixing the data the VM's are responsible for on the same datastore as the OS's. Perhaps if you were to migrate the OS vmdk's to their own datastore with dedupe enabled you could save some space there. Then, depending on the data types and applications you are using on the various VM's, you could create multiple datastores to house the similar data types keeping the fundamental capabilities of the dedupe feature and your needs for recovery of the data in mind all the while.
Using more than one datastore in VMware is one of those things that sounds and looks uglier than it is. In many cases it is a necessity for data protection and performance. Especially when you start talking virtualized Oracle DB's.
So circling back to the math we did earlier. Let's say you are running Windows 2008 R2 across the board (wouldn't we all love things to be that simple!). That could mean that you have 30 VM's with an average of 30GB's or so per OS instance in just the OS disks; that is ~900GB in full non-deduplicated storage. If all of the vmdk's for the OS's that add up to this amount are stored in one datastore with dedupe enabled, you stand to experience a *substantial* dedupe rate. I will defer you to TR-3505 for estimations on the rate though. Let's just say for the fun of it that you score an 80% dedupe rate...I believe that is actually fair. At that rate, you stand to save 720GB right there.
So you can start to see how layout of the storage you use can have a substantial effect on how much savings you glean from the enhanced technologies in the array. Let us know what you decide to do and how this all pans out. We are rooting for you!