The selection you choose drives what is presented to the VM. So, if you say 2 CPUs and 4 cores per socket, the VM will think it has 2 physical processors that each have 4 cores. This can make a difference in licensing situations and functionality. For example (I don't know if this is still the case) at one time Windows Server standard only recognized up to 8 CPUs, and Windows 7 desktops would not recognize more than 2 physical processors. So if you want to run a virtual Windows 7 with more processing power, you can give it 2 CPUs with more cores per CPU. Then that OS will have more processor threads to leverage.
No matter what you pick for CPU and cores per CPU, it all maps to logical processors on the ESXi server. So you multiply the CPU x the cores. For example 2 CPUs x 4 cores = 8 logical processors. This matters for scheduling purposes. Whenever the VM has instructions that need to be run on processors, ESXi needs to schedule that time on the physical processors. It needs to grab the total number of logical processors for each cycle of time the VM gets. So the more you give it, the more it needs to consume to run.
A logical processor on the ESXi server comes in the form of CPU sockets x cores x threads. For example, the Intel Xeon X5650 had 6 cores and 2 threads per core. So if you had 2 of those in a server, the total number of logical processors for that server would be 2 CPUs x 6 cores per CPU x 2 threads per core = 24 logical processors. Each of those logical processors can be allocated as either a socket or a core to a virtual machine.
The total amount of clock cycles available to the VM would be number of logical sockets x clock speed of CPU. So if you give a VM 2 CPUs x 2 cores per CPU = 4 logical processors and the clock speed of the CPU is 2.4GHz, then total available processing power is 4 x 2.4 = 9.6GHz. In actuality, this really depends on the scheduling done by the hypervisor and how many other VMs are vying for resources (not to mention any resource reservation/pool settings you might have configured).
The way the UI is set up is a bit backwards. When you assign CPUs, you're telling it how many total logical processors you want to give the VM. By default, these will have 1 core per socket resulting in number of sockets = number of CPUs assigned. When you choose cores per socket, the system divides the number of CPUs by the number of cores to back into the number of physical sockets. So in your case, the maximum number of logical processors you can assign to any VM is no more than the total on the system (12). if you choose 12 CPUs, your options are 1, 2, 6, and 12. 12 / 1 = 12 sockets; 12 / 2 = 6 sockets; 12 / 2 = 6 sockets; 12 / 12 = 1 socket. If you choose 8 CPUs, your options are 1, 2, 4, 8. 8 / 1 = 8 sockets; 8 / 2 = 4 sockets; 8 / 4 = 2 sockets; 8 / 8 = 1 socket. So it's a backwards way of asking how many sockets and how many sockets per core. You tell it how many logical processors you want and how many sockets per core and it infers the number of sockets using the math I just did.
To your final question - It does kind of depend on the utilization you expect for these, but a good mark is 2 CPUs, 4 cores per socket should be fine, so choose 8 CPUs, 4 cores per socket and it should tell you it will have 2 sockets (8 / 4 = 2 sockets) . If this is just a lab scenario then you don't need very much at all, but if these were production servers, you would want to think about total transactions and the profile of those transactions (i.e. is this read or write heavy)? And storage profile would matter as well.
