It's both yes and no as far as my understanding goes, but not yes for the reasons you want. That 1 vcpu allowance you gave your virtual machine does not mean it will always stay on core #2 of cpu #1, but it does mean it will never use >1 core.
Since you have only one virtual machine on your server you are not seeing the workload distributed over multiple cores because the CPU scheduler never sees it necessary to move it off that single core. However, if you were to start hosting more machines that see varying workloads and even if they all were assigned a single vcpu then any one machine may not necessarily be running on the same physical core at all times.
The work can be distributed over multiple cores depending on how ESXi's CPU scheduler sees fit. That being said, VMware still cannot split a single vcpu over two physical cores at the same time. All it can do is migrate those vcpus to another physical core if the load balancer thinks it beneficial to do so, ie- if one core becomes overwhelmed with work and another core is sitting idle, ESX will migrate the vcpu to that idle core.
I would take a read over this article starting on page 6 and more in section 3.3.1 on page 10 if you really want to see how the design works: http://www.vmware.com/files/pdf/techpaper/VMW_vSphere41_cpu_schedule_ESX.pdf
This is not a limit of VMware but of how processors and software work in general. The idea you have is sort of a holy grail of multi-cpu computing, getting a single threaded application's workload to be distributed over multiple cores in order to increase performance. It's pretty much the exact opposite of hyperthreading: instead of getting one core to do two cores' work to increase parallel execution bandwidth, you'd be getting two cores to do one core's work twice as fast. Anyway that's probably way more technical than you wanted it to be.
tl;dr: Nope, but if you figure out how you might not want to go telling everyone around town how to do it unless they're offering a couple bucks :)