Eeghads! Just FYI, CPU affinity is almost never what a vendor actually wants, even though they think they do. I can imagine there are valid use cases, but I've spoken with several vendors who recommended this, and they were all mistaken.
From what I gather in your summary, the application is sensitive to CPU latency. If the physical compute capacity is there, shares and reservations will address latency. Is latency the only reason they want to set affinity, or are there others? If there are others, find out what they are, because there's a good chance those are also invalid reasons. CPU affinity tends to exacerbate any issues you're having with CPU ready times, and can often cause the application MORE CPU latency than it would without it. Yes, you can set CPU reservations to address those issues for that particular VM, but you've just made life more difficult for the CPU scheduler. DRS doesn't factor in CPU ready time either, which means it won't necessarily be moving those other VMs off that host, even if they're co-stopping like crazy. While we're on the subject, this VM would need to be excluded from automatic DRS migrations, since you can't vMotion with CPU affinity configured. This also means the VM needs to be powered off whenever its current host goes into maintenance mode.
Anyway, checking "reserve all guest memory" won't affect memory locality. It'll just back all virtual memory pages with physical memory pages (another interesting side effect is that the VM no longer creates a swap file on boot). If you REALLY have to set CPU/memory affinity, the memory affinity can be set by editing the VM settings, resources tab, select Advanced Memory, and you can configure NUMA there. Also, if you hadn't seen it already, CPU affinity is configured in the resources tab as well, under Advanced CPU.
I'd strongly recommend you challenge the vendor and ask them if CPU reservations are enough. The CPU scheduler already is NUMA aware. How many vCPUs are they asking for, anyway? Unless they want more than 8, it's unlikely to split the VM.