Bare-bones nested set-up really doesn't need much in terms of resources but if you are planning on running some form of test/mock workload on it then the requirements of that will determine how much CPU/RAM/Cache/Capacity each host will require. The main 'minimum' is the memory assigned for Disk-Group overhead which is based on base+number+size:
It will fail to create Disk-Groups if there are not enough resources available.
How you decide to carve up the storage depends on how many devices you have summing to 1.2TB SSD and 4.5TB 'storage' and how many hosts you want to have in the test-cluster e.g. if you have 3x400GB SSDs, 3x1.5TB HDDs and want a 3-node cluster then it might make sense to assign each drive as a datastore, create vmdks for each host VM and use each one as cache/capacity-tier. Though if you have 1x1.2TB SSD and 1x4.5TB HDD then there isn't really going to be any benefit (that I can see) from splitting it out and should just put it on 2 datastores (one on SSD for cache-tier, one on HDD for capacity-tier) and then create the vmdks on each accordingly.
Do note that nested (vSAN or anything else) can be quirky and unpredictable at times so I wouldn't be expecting the world from this with regard to performance or stability - that being said it can be invaluable for gaining experience and learning the product.
There is always HOL if you want something easily spun-up for 'disruptive learning' aspects:
vladan does a good overview of the actual configuration aspects here:
Yeah, typically my nested lab is unstable for for academic purposes it's adequate.
I'll give vladan's steps a try.