Yes, you should be able to compile Jack using your either the supplied compiler or your compiler, and use your VM translator to produce an ASM that will run on the CPUEmulator.
In addition to the .vm files generated by compiling the Jack sources, you also need to copy the n2t/tools/os/*.vm files into the directory before running your VM translator. Otherwise there will be calls to nonexistent functions. The calls will have an @targetFunction but since there is no corresponding (targetFunction) the assembler will assign a RAM address to targetFunction which will result in a jump to an unintended address and most likely a crash.
The other issue that you may run into is that your generated ASM may be larger than 32K. There are several things that you can do to reduce your generated code size. The two biggest VM commands are call and return. Notice that every return generates exactly the same ASM code. Your translator can write this code for the first occurrence of a return command, and for all other returns it just needs to jump to that code. You can do the same sort of thing for call, but it's a bit more complicated than just a jump since you need to pass the return address, number of arguments and target address to the common code.
Thank you for all the information. I had noticed my ASM file contained 46,800 lines, and was too large to load. I had seen one of the optimization threads earlier, and now will study them in more detail.
I wonder whether I could remove some functions from my local copies of the *VM OS files before assembling the whole folder containing them and my Main function. It may be that there are too many calls from one module to another, that I can't remove any function without leaving a hole.
One of the optimizations talked about in the threads is having your VM emulator do a prescan of all the VM files that are to be translated and identifying uncalled functions so that they can be skipped when the ASM code is being generated.
When translating projects/11/Pong, my translator reports: