IANAL, but here is my opinion of what is allowed within the limits of GPL:
distribute the combined work "A - B" in public: fine, can be done under any proprietary license
create a wrapper lib D for C by Y: fine, this does not imply that A has to be put under GPL
use the combined product "A - D - C" internally by Y: also fine, GPL does not require to open source A as long as the combination is not distributed to the public
distribute the combined work "A - D - C" in public: this will require A to be open-sourced and to be put under GPL (and it does not matter if X or Y distributed this combination; additionally , if Y wants to do this that, they would require a distribution license for A from X, of course)
The interesting question now is: can D & C be distributed separately as open source under GPL, A&B (or just A without B) be distributed under a proprietary license, and the end-user replaces B by D&C by himself ?
Here the final modification to "A-B" which makes A dependent on libs D & C is done by the end user - after distribution. So one could argue that the final modification is only done internally by the end user. And it seems that this indeed is possible without violating the GPL - and what you get is a working combination of "A-C&D" where A is under proprietary license and C&D under GPL.
Of course, a lawyer or a judge may have a different opinion on that. To get a final answer, I think you must wait until someone tries it out and a second one sues him.
I guess for most systems, it will be hard to create such a constellation without designing "A" from the beginning in a way so it will work seamlessly with either B or C. And in this case, one could come to the suspicion that A was somehow derived from C.
EDIT: thinking a while about this, a similar situation came into my mind: writing and distributing GPL licensed plugins for closed-source applications. Lets take for example, Photoshop. I don't think someone would seriously try to enforce Adobe to open-source Photoshop just because there exist some GPL plugins from third-party vendors. Here, not even a "wrapper lib" is needed since there exists a well-defined interface. However, would it change the situation if Photoshop would incorporate some of its central functions from a GPLed third party plug-in? I think for such a case it may become really hard to decide where to draw the line, at which point the closed-source product is a work "based on" the GPL lib.
EDIT2: There are dual-license libs available, with a GPL license for non-commercial use and a proprietary license for commercial use like this one, for example. So your "loophole" would mean to develop a product based on such a lib (using the commercial version, so GPL does not apply to your product), deliver your product as closed-source without the lib to the public and let the end-user get and install the GPLed version by himself. For such a case, I guess the vendor of the lib will have a good chance of sucessfully sue you for license violation (if you don't pay for his lib, of course). Is it worth the hassle? Probably not. Especially in the example I linked to, you would have to buy the lib either, since the pricing is not dependend on how often you sell your product, but only how many devs are using the lib during development.
Finally, because of those legal risks, if I intend to use open-source libs within a closed-source product, I would avoid GPL libs if possible, and not try to make use of this "loophole". LGPL or GPL with linking exception is much safer, or any kind of non-viral OS license.