Presuming you can only learn the CPU's ID through through the VM itself, then an attacker with access to the hypervisor, plus at least one private key extracted from a sacrificial CPU of the same model, could just have the VM report the extracted-from CPU's serial number, and then use the respective extracted private key in their SGX enclave emulation. And this would check out with Intel.
Or, of course, a lot more simply, you could just make up your own keys instead of extracting any Intel keys, and then have the VM rewrite any Intel CPU root certs it finds in the VM's memory to be the attacker's certs instead (and any hashes of those certs be the hashes of the attacker's certs, etc.); such that messages signed by fake-SGX validate within the VM, and messages encrypted by fake-SGX decrypt within the VM, and messages encrypted by the VM decrypt within fake-SGX. In other words — don't keygen the user's workload; crack it. The SGX enclave is very rarely used in such a way where the component checking it is running on anything other than the same VM calling into it, so why bother worrying about what other untainted machines communicating with the enclave might see? That'd be like worrying about what more-sensible third-parties might tell your victim in a confidence scheme.