The UAC prompt is an all-or-nothing proposition, you either allow the program administrator access or don't run it at all.
That doesn't necessarily mean that you can't achieve your goals in other ways. For example, if you want to give a user access to the address space of a particular process, you can change the permissions on that process. Similarly with files and registry keys, though it is usually inadvisable to change permissions on the parts of the file system and registry that don't belong to you.
This question on Stack Overflow discusses ways of getting an application that requests administrator access (but doesn't actually need it) to run anyway.
Theoretically you can grant individual privileges (e.g., backup privilege) to individual accounts, but while the kernel still supports this, UAC breaks it. Almost all admin-level privileges you could grant someone can be leveraged to gain unrestricted administrator access anyway.
The more usual approach if you want to allow a user to perform specific administrative tasks is to write a system service to do the work on the user's behalf. This typically involves splitting the application into two parts, one that runs as a system service and has administrator access and one that runs on the user's desktop and does not.
Addendum: it is no longer true that UAC breaks granting individual privileges to individual accounts. If you enter your own (non-administrator) username and password at the UAC prompt, the elevated process will receive whatever individual privileges your account has been granted.
