First of all, be aware that what you're attempting is extremely difficult to get right. For example, a lot of tools in Windows are in the System32 (and SysWOW64, where applicable) directory, so you might be tempted to deny Execute permission on that directory (except on perhaps a few critical EXEs), but that will prevent loading DLLs that are required for nearly every single Windows program. Some shared / widely-needed stuff is in Program Files as well, so the same risk applies there.
Also note that Windows doesn't make it easy to do stuff like this. By default, any user can bypass directory traversal restrictions (as on *nix, the Execute bit on a directory ACL controls the ability to access the directory's contents, but unlike *nix, this restriction is ignored by default). Also, while Windows ACLs are inherited by default, some items do not use inherited permissions. For example, the C:\ProgramData directory does not inherit permissions from C:\, and by default allows any member of Users (which by default includes Authenticated Users) to create subdirectories and have full control over those subdirectories. This makes it very difficult to create a user account that can only write to one location.
With that said, yes, this is possible. Windows ACLs are validated against a process token in the following order: User Deny, User Allow, Group Deny, Group Allow. Thus, if a user is a member of both an allowed group (such as Authenticated Users, i.e. anybody who logged in using credentials) and a blocked group (such as the built-in Guests, or a custom group you create and perhaps add to Guests), then the user will be blocked. However, if you also explicitly grant the user access in that ACL, that overrides the group protections. This means you can block a group from doing something globally, then grant its members access to specific resources.
An alternative approach to ACLs would be to use AppLocker ("Application Control Policies"), which lets you do things like disable all programs except for a whitelist specified by publisher signature, file hash, or so on. A full explanation of using AppLocker is outside the scope of this answer, but you can find information online, or start playing with it yourself by using Locals Security Policy editor (
secpol.msc). Note that messing up badly enough can make the machine unusable. Note that AppLocker is generally only usable on Enterprise-or-better editions.
There's no equivalent (to AppLocker) way to restrict file access, but you can do this using Windows' Mandatory Integrity Control. If you restrict a user to only running a certain set of applications (or only running applications from a certain directory), you can specify that the EXEs (or directory) have a Low integrity level. Any process launched from those EXEs will thus also only be Low integrity, which will prevent it from writing to any file or directory with an integrity higher than Low (by default, everything is Medium integrity). You'll need to be careful this doesn't cause problems - for example, programs that generate log files will need to be able to write to their log directory - but it can be done.