Robert:
The problem is that you're trying to use unix tools to view and replicate windows ACLs - I'm not aware of anything that'll do that, unless maybe you mount the volume as a cifs share. You say that NTFS permissions mean that "Windows ACLs always win,", which isn't really right. Windows ACLs are applied; there is nothing to win or lose, as the only ACLs are windows'.
The volume is NTFS, which means that NTFS permissions are in force. NFS doesn't know anything about those; the ACLs you see on the NFS mount are unreliable as far as determining ownership and rights, and trying to use rsync to copy the ACLs will fail, because rsync only sees the ACLs NFS shows. The only reason that the owner shows up after you set up user mapping is because the filer now has something to map the user to, where before it didn't. Again, seeing the owner on the unix side doesn't necessarily mean that is the owner on the windows side.
Hope this helps...
Bill
This is also why your second example is failing - you've given root access to the NFS share, but not necessarily to the NTFS data within it.
Is there any way to change the permission structure to standard NFS long enough to complete this copy.... and then change it back to windows mode?
Technicall, yes, you can set the volume to unix permissions, copy the data, then set it back to NTFS, but you'd still face the same problem copying, as NFS won't recognize the source NTFS ACLs, and converting to NTFS blows away any unix ACLs (pretty sure on that, anyway).
Your best bet is going to be using a windows based copy tool (e.g., Robocopy) - that way you know you're replicating the ACLs. The permissions won't look right on unix; in my experience there is really no way around this. As long as your usermaps are set up right, unix IDs will map to windows IDs and all the AD access group stuff should work fine. I've primarily worried about the opposite - mapping windows users to unix ACLs - but my understanding is that the reverse should work fine..