It is not possible the way you want it, where if one user executes the file then it is executed setuid, but if another user executes the file it is executed without setuid. The setuid bit is not included in access control lists. It is either on for a file or off.
You can get partially toward your goal. You can allow only certain users to execute a setuid file, but other users will be forbidden from executing it at all.
For example, consider the fictitious "privileged_command" program. If you want to make it setuid but only allow members of the adm group to run it through an acl, then you can do this by:
$ chown root.root privileged_command
$ chmod 4000 privileged_command
$ ls -l privileged_command
---S------ 1 root root 152104 Nov 17 21:15 privileged_command
$ setfacl -m g:adm:rx privileged_command
This is a very simple example, and very doable with just group permissions. But you can go on to use setfacl to make a complex set of users/groups who can and can't execute the program. The only issue is, everyone who is capable of running the command will run it setuid. Anyone else will just get permission denied and won't be able to execute it at all.
This is as close as I can think of get to what you are actually asking. That being said, what you are asking is probably a Bad Idea™. Best practices for extra privileges are for users who are authorized to exercise those privileges to be required to actively assume that authority when and only when they intend to act with that authority. This is the whole purpose behind sudo. Making certain commands automatically act with different privileges depending on who is executing them is a recipe for accidental misuse. That's the reason why you don't normally just log in as root all the time.
Also, the use of ACLs this way is a recipe for later security holes. ACLs are rarely used, and even more rarely needed. In this case, using them to control who can run a program setuid, it's not immediately obvious who has what privileges, there is no central file or repository showing who has what authority, or what ACL conditions are on which files. It can quickly become an administrative nightmare.
I won't say that there is never a place for using an ACL, but I can count on one hand with a lot of unused fingers the number of times I've seen a convincing case that it's a good idea.