Your vendor is correcty when they state this:
"I've requested that our infrastructure vendor to increase the vCPU size from 10 vCPU's to 14.. But they've come back with the following..
Your Host is a 4 socket / 10 core server with 512GB of Ram or 128GB per socket, The VM is configured with 190Gb of vRAM. Therefore, part of the vRAM is located outside the NUMA alignment and as advised, the best practice is to limit the number of cores to 1 socket.. Maybe you should look at splitting the server into multiple smaller VM's."
If your ESXi host has a 4 Socket / 10 core 512GB of RAM availble, they are correct in stating tha you should stay at 10vCPU and 128GB of memory to stay with the NUMA complaince. However if you where to jump to 14vCPU or 20vCPU with more memory instruction sets may cross the NUMA barrier. Lets look at how this works a little more:
Lets take a 2 Hosts with the following Configuration:
2 Socket 4 Core
64GB of memory
Now when VM1 runs all CPU scheduling and memory scheduling stays in one block, as each CPU in the host has a memory block associated with it and its requests. You typically see this very clearing on the board layout if you pop the case off. So all instructions that CPU has to do stays local to it which is VERY FAST. However if you look at VM2 since it is using more vCPU then a socket can handle any instructions for the 5th and 6th vCPU and or memory over 32GB now has to go across the CPU bus or the NUMA bus in the picture. This is still fast just not AS fast if you where to keep it local on the same BUS. This is what your vendor is trying to tell you.
You could try and bump the vCPU & Memory to what you want and you may get a mimamul gain, however typically when your jumping the CPU bus for CPU & Memory the returns tend to cap out and your gains are mimumal. However there is no harm in trying. To give you an example we had a SQL deployment recently with simular requirements. The psyhical was 16 core 128GB memory SQL BOX. When we virtualized it to stress test it we saw better gains with 8 CPU 64GB of memory vs the 16vCPU 128GB of memory. This was also largely in part due to the way that particular SQL box functioned, however typically once your jumping that barrier you will eventually hit a wall where throwing more CPU / Memory at it will not get you good returns and your better off scaling out into smaller VM's to get your performance.
I hope this has helped
The ESXi CPU scheduler is smart enough to figure the physical topology and figure out resource allocation in the best possible way. In later version of ESXi, there is wide-numa, a virtual machine that has more vCPUs than the number of cores per NUMA node is referred to as “wide” virtual machine because its width is too wide to fit into a NUMA node. wide virtual machines are also managed by the NUMA scheduler by being split into multiple “NUMA clients,” each a wide-VM can be split into smaller NUMA clients that fit within the size of the NUMA node in terms of physical CPU cores. A home node is then assigned to each client.
In you case, there is nothing wrong with adding more ram, as long as you are running recent version of Windows/Linux and ESXi. This is just a temp situation as you are already planning to break up the data set. As JPM300 already pointed out, there is little again, you are better off scaling out. The management overhead of monster VMs is little high, i.e vmotion between esxi host could take long time unless you have 10gbe vmotion network. etc
Please refer to CPU scheduler whitepaper, it is a good read if you time to spare.
The CPU Scheduler in VMware vSphere 5.1 : http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf
^What vfk said 
vfk You just had to 1 up my crayon drawing didn't ya :smileysilly: good work on the description!