It's impractical and typically overt, if a VPN where to attempt to use "man-in-the-middle" attacks.
More detailed answer:
There are other ways that this could be done, without your knowledge, however, it would only exist on VPN's that force you to use their own proprietary software.
I'll try to explain the paradigm of how these attacks work, in the context of how you'd assume a VPN would use them -- and then I'll explain the actual, real-world paradigm.
In theory, you'd imagine that Computer-Client (A) ... connects to proxy/VPN server (B) ... connects to web server (C).
In the case of an actual "proxy" (you'd never use a VPN service that required you to access via proxy, for multiple reasons) -- that would be valid to some degree.
However, in a true VPN, the traffic is passed through the VPN server identical to a router.
To put that more simply, imagine how traffic goes from you to a web-server, and the reason SSL was invented...
Computer --> Router --> ISP --> Switched, Routed, and Tunneled Private/Public Net --> Router -- Web Host.
When you think about that, it should occur to you that anyone in that chain can swipe your data/credentials. Whether it's a nefarious router/proxy on your side, the ISP, the network inbetween, or the router on the host's side.
By inventing HTTPS using SSL, you tunnel from your browser to the website.
More simply: the traffic that anyone sees, between you and the website, is encrypted traffic that is worthless to any thief inbetween.
With a VPN your are creating a tunneled network connection between you and the VPN host. From there, the traffic goes out onto the public network. If you are using HTTPS/SSL, then the VPN host is just as helpless against obtaining your information as in the conventional paradigm I explained above.
-- EXCEPTIONS --
(1) Non-HTTPS traffic; however, this can be stolen by anyone between you and the host; introducing a VPN just allows them the same access to steal that information as any other intermediary.
(2) Proprietary software. In theory, a private software package could do some unique things, like proxying and encrypting on the back side of the proxy (after the VPN). Or they could install their own SSL signing authority, and the tunnel you create could be a two-way (once to them, another time to the host); however, it would be difficult to do this without a warning from your browser (long story).
--- SUMMARY ---
The simplest answer is that as long as you use HTTPS and standard methods of connecting/tunneling, you are fine 🙂.
If you use HTTP, while you are at jeopardy, this is not an issue because you're also at risk without a VPN. Furthermore, there is no sensitive material that requires credentials which is not behind an HTTPS/SSL connection.
--- DISCLAIMER ---
I've over-simplified this to a slight degree to make it more readable. Also, because some people complain that my posts are too long. There are exceptions to some of the rules I've explained and more complexity -- however, my explanation should cover 95% of all real-world issues and for purposes of the context of this question, will be100% accurate in pragmatic terms.
I hope that helps 🙂