The first thing you'll want to decide is blade vs. standard chassis server. The UC VM's themselves won't care, so this is a matter of preference on hardware deployment.
A good place to start in regards to sizing is really in looking at the requirements of the VM's themselves. In the UCS world, CUCM, UCXN, and UCCX have VMware templates provided by Cisco that will drive the CPU, memory, and HD space requirements for each VM. In a 1:1 redundancy deployment, you'll want two UCS servers too, so you'd have a layout of something like this:
Server1
CUCM PUB
UCXN Pub
UCCX Master
Server 2
CUCM Sub
UCXN Sub
UCCX Secondary
You'll want to think carefully about where each VM lives on each server if this is over a WAN though (CUCM Sub should be physically close to phones, as they are should register to it). The biggest component (I think) to your referenced build will be UCCX (unless CUPS is bigger, I haven't touch CUPS yet). In my experience, this is the most resource intensive component of the 3 I reference above, both in hard disk requirements and actual CPU/Mem demand.
In our environment, which is actually similar to what I've listed above, it's running on a pair of UCS C210 M2 servers. It was previously on C200 servers, but Cisco recommended we resize to the C210's to ensure adequate CPU capacity.
The only thing I can't comment on are the additional requirements around your CUPS deployment. I don't "think" that'd take you into a higher model than the C210, but you'll want to check the hardware requirements for your sizing.
The installation guides for each UC platform component are quite helpful in regards to helping to properly size the environment, and would carry over to VMware (if the guides don't specifically mention it anyways) based on your existing sizing requirements for device/user counts.
And lastly, I'd caution on density of VMs on physical servers. When having to do maintenance on the server itself, the more VMs you have on it, the more of a pain (read: nightmare) it can be to actually do maintenance to that server.
If I could re-deploy our environment, I would keep CUCM and UCXN as VM's, and either put UCCX on bare metal, or at least on its own servers. The failover path between UCCX nodes is far less graceful than failing over CUCM and UCXN, in regards to agent and customer facing impact (failing over UCCX is very disruptive to logged in agents, and the CAD/CSD applications do not handle it very reliably in our real-world environment).
