My approach is to not use file/directory level file permissions; use file share level permissions, and set the whole server filesystem data drive to Everyone Full Control (which becomes moot).
Over the years (10+), I have found that NTFS permissions are more complex and leads to more errors. If the permissions are set wrong, or the inheritance gets broken, you expose data and its hard to find and see it. Plus, you are exposed to the move/copy problem as you say.
Places where you have to use directory/file level ACL's; I know of no other solution than health checking the thing on a regular basis.
There is no analog to a "noexec" mount for filesystems in Windows. Microsoft's conception of the simple "Read" permission includes the right to execute (since execution really is just the loader reading the image into memory).
You can modify the "Advanced" version of the permission to remove (or deny) "Traverse Folder / Execute File" permission. This will prevent double-click or command-line execution of .EXE files. .BAT and .CMD files will not execute from a double-click in Explorer, but they will still execute from a command prompt or using the syntax "CMD /c " from Start / Run.
Changing the permission breaks the "analogy" of a "noexec" mount since "noexec" doesn't require any modifications to the permissions of the mounted volume.
You'd be better off looking at Software Restriction Policies as a way to accomplish what you're looking for. This facility changes the behaviour of the API used to execute programs to restrict the paths (or by digital signature or cryptographic hash) from which programs can be executed. Assuming your local users do not have "Administrator" rights, this functionality would be effective, to some extent.
Ultimately, though, if there's any filesystem location on the computer where the user is permitted to both write files and execute, the user could copy programs from the restricted-execution paths to this location and execute the program from there. You would need to be very diligent to insure that there are no such locations.
Alternatively, Software Restriction Policies can be used in a "default deny" mode, wherein only specified paths (or digital signatures or cryptographic hashes) will allow execution. This is also fairly difficult to setup, since you need to test all your applications to be sure that their execution is successful.
You don't mention what version of Windows you're talking about. For Windows 7 and Windows Server 2008 R2, Software Restriction Policies is part of AppLocker and the functionality is similar.
Best Answer
I don't think its possible to do this because MOVE isn't a permission in itself. A move operation on an NTFS object involves creating a link in the target directory location and then deleting the link from the source directory location - the delete permission is therefore an inherent part of moving an object.