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.
To answer the third question first, the fact that your program uses a library licensed with license X does not necessarily mean that your program must also use license X.
For permissive licenses, like BSD, you are completely free to choose a different license for your own code.
When the library uses a strong copyleft license, like GPL, then you can avoid a lot of legal questions and uncertainty by using the same license for your code.
The reason for this is because copyleft licenses require you to distribute the entire product that makes use of the copyleft licensed source under the copyleft license conditions. So, when you distribute your program, the GPL conditions of having to provide source code apply to both your code, the PyQT library and the additional BSD-licensed library that you use.
Neither the BSD nor the GPL license prevent you from asking money for your program, but they also don't forbid anyone to buy the program from you and redistribute it further without asking money for it.
The reason that PyQT is available both with the GPL and a commercial license is to make it possible to write commercial applications based on PyQT without having to release your source code.
Best Answer
As Ross Patterson notes in his answer, the JavaMail library is not simply GPL licensed, but GPLv2 with Classpath exception. This is an important distinction, because it makes a world of difference for the answers to your questions.
The Classpath exception to the GPLv2 license effectively restricts the copyleft nature of the GPLv2 to the JavaMail library itself (in a way similar to the LGPL does).
To answer the specific questions:
As the classpath exception restricts the GPL terms to apply only to the JavaMail library, there is no problem in having a non-GPL work (library or program, in this case an MIT-licensed library) depend on it.
Even if CS2J depends on a library that uses the regular GPL license, the CS2J sources themselves can have a different license. The only 'difficulty' then is that the license must be compatible with the GPL, because the terms and conditions of the GPL would have extended to CS2J.
Due to the Classpath exception, the copyleft of JavaMail is contained within JavaMail itself. Without that exception, the copyleft would have extended also to your software.
Requesting the authors of CS2J to physically include JavaMail in their CS2JSupport.jar would make the CS2JSupport library a derived work from JavaMail that must be licensed under the GPL (with or without the Classpath exception), so that would not give you a route for exemption from the GPL copyleft terms. At best, the situation remains as is (your software depends on a GPL library with classpath exception) and at worse you suddenly have a dependency on a full GPL licensed library and must open up your own software as well.