However, in the more invidious application, the data filling and overflowing the buffer is carefully constructed to be a series of opcodes that will land on the stack, and the return address will be overwritten to point to this malicious set of opcodes, and then you're in a world of hurt. NX-protection prevents this by making the stack pages non-executable - you can overwrite the return address, but you can't pass execution on to your malicious payload.
HOWEVER, NX-protection cannot prevent the return address from pointing to some other location in memory, and passing execution off to that location - in particular, you can pass execution off to some location containing convenient OS opcodes, which you can then use to further your nefarious scheme. This is the whole rationale behind the Metasploit project, to document the locations of Windows opcodes in memory, so that they can be exploited in this manner. But it's not unique to Windows - if you know the location of vulnerable opcodes in OS X, you can call them from a stack exploit just as easily as in Windows, and NX can't prevent it, because it's passing execution off the stack.
Absolutely true. But you have to have either pre-installed an executable or modified the opcode to make it malicious (although an existing code that erases the HD would do... ;^)>) That gets back to making this a more sophisticated attack than just a buffer overflow with self contained malicious code that would execute from the stack.