The phrase "security barrier" can be ambiguous. I think it may be more useful to consider the concept of a security guarantee, sometimes called a security boundary. More here.
Basically, a security guarantee is a statement about the intended behaviour of the software.
Any way to violate a security guarantee (within the appropriate scope) represents a security vulnerability, i.e., a bug or a design flaw. In the case of a security vulnerability in Windows, Microsoft's general policy is to at least attempt to correct the problem. In most cases, this means a security patch, usually via the monthly cumulative updates.
NB: this is not a legal or contractual obligation.
So what about UAC? Well, it depends on both the scenario and the system configuration. Let's go through some of the more obvious and/or interesting cases. [Note to OP: I think you're mostly interested in the last case, so feel free to skip straight to the bottom.]
Default Settings, Admin User
In this case, when you attempt to perform certain tasks that require administrator access, you get the Yes/No dialog.
There is [I believe] a security guarantee that no application (which does not already have administrator privilege) can press the Yes on your behalf, and that the information provided by the dialog about which application is being launched is accurate. [Proviso: I'm not entirely sure what the story is concerning potentially malicious accessibility applications. Can anyone expand on this?]
But in this case that's all irrelevant, because there isn't any security guarantee that an application cannot obtain administrator privilege without bringing up the dialog, and in fact there are a great many well-known techniques for doing so. More here.
Always Notify, Admin User
If you have turned on the "Always Notify" UAC setting, then [I believe] there is a security guarantee that no application can directly gain administrator access, via UAC, without the dialog appearing. More here.
... but still no guarantee that the application will use the admin privileges in the way in which you are expecting. You get to see which application is being launched, but it is your responsibility to check that it is the one you were expecting. Also, you don't see the command line by default, only if you ask for more details; if an application that you trust has dangerous command-line options, a malicious application might take advantage of that, hoping you won't notice them.
... and if any third-party applications are running with admin privilege, they might have vulnerabilities allowing a malicious application to take control. Windows does take some steps to mitigate this risk, e.g., you can't just use a plain old shatter attack, but it can't eliminate all possible methods one application might use to attack another.
... besides, in a typical enterprise environment you can take advantage of the fact that UAC doesn't operate over the network, as described in Joshua's answer. This sort of attack is I suspect even easier and more practical than it sounds.
In practice, these issues significantly limit the effectiveness of this security guarantee, even in the absence of any security vulnerabilities in Windows itself.
(Such security vulnerabilities have existed; for example, Joshua points out that at one point the Task Scheduler allowed an admin user to create elevated tasks without first requiring elevation. Once discovered, it is likely that they will eventually be patched, but they are also likely to be considered low priority.)
[The current user registry hive provides a huge attack surface for a malicious application to attack elevated applications, particularly if you can make changes before the elevated application is launched. Does anyone know whether there are any standard techniques around this? The most obvious approach would be to put a malicious DLL onto the user's PATH, I suspect many applications would be vulnerable to this simple attack.]
Non-Admin User With An Admin Password
This is the case where the logged-on user account is not an administrator, but the user knows an administrator password. All the previous caveats apply.
... plus, a malicious application might mimic the dialog to capture your password, as already discussed in Michael's answer. There are some mitigations in place to make it difficult for a program to use an administrator password to gain admin privilege, but my understanding is that this is not a security guarantee. [Can anyone confirm whether there is a known way to elevate once you've got an admin password? Perhaps via the Task Scheduler, for instance? In many cases this is moot, I guess, since once you've got the password you can use it to RDP in or access the C$ share or whatever from another machine.]
The only really safe approach here is to never provide the administrator password when prompted; instead, switch user and log in with your admin account whenever necessary. Of course this is enough of a pain that only the most punctilious systems administrators will stick to it consistently.
... obviously, if you're doing that, you also need to follow good hygiene in other respects, e.g., you don't download an installer in your non-admin account and then run it from your admin account. But then, you shouldn't really be running a web browser from your admin account either, so catch-22.
Non-Admin User Without Admin Password
We're on firmer ground here. There is an unambiguous security guarantee that a non-admin user will not be able to run an application with admin privilege without providing an administrator password. This isn't new to UAC, but UAC doesn't remove the guarantee either.
Vulnerabilities violating this guarantee are usually called local elevation of privilege vulnerabilities. In most cases they are considered lower priority than vulnerabilities that allow remote attacks, but Microsoft will usually patch them reasonably promptly.
[OK, that depends on your definition of "reasonable". :-)]
