No, this attack is not feasible. Believe me, I've tried. Now when I say I've tried it, I was not writing a virus or something to steal passwords, I was writing software where the user was fully aware that they were using a custom DNS server which intentionally lied (based on their rules) in conjunction with a HTTP proxy. This is exactly what you describe, "poisoning" the DNS to basically lie to the software making the lookup and point it wherever you really want to the traffic to go. There are several issues that arise once you throw SSL into the mix.
1) Even if you have a custom DNS server or piece of software monitoring and modifying the DNS packets, there is no way inside this protocol to tell if you are dealing with requests for HTTP/HTTPS, or who knows what. So, you cannot tell what protocol the request is for. Even if you inspect the packet and look for the hostname, it will appear as "mail.google.com", not "https://mail.google.com", as an example.
2) In order to bypass the browser warnings, you need a few things. First, you need a trusted root certificate for your proxy or malicious server. Not gonna happen. Even if you manage to get the user to accept and install it (which windows basically makes sure to make the user feel like they're accepting an envelope with anthrax if they say yes), most browsers have their own trusted root authority certificate stores that they check against. So now you've gotta get the user to go out of their way to install your cert in whatever flavour of browser they're using as well.
3) Step two isn't enough. Now, if you've gotten that far, you have your malicious cert for your malicious server. Now you need to dynamically issue certs for every single host that a HTTPS connection is made or else guess what, the alarms still go off. These browser warnings aren't like the old days. Google chrome won't even let you proceed when it detects this going on, no matter how much the user wants to be careless with their own security.
Also, without doing any of this failed trickery discussed in 2 and 3, you get even less. All you can see on a socket level is the socket open from the app requesting the lookup, you see the host resolution happen over DNS, then a new TCP socket open attempting to connect to the host requesting a secure connection. The socket header doesn't contain anything except this basic request. As soon as the connection is made with the server, a handshake takes place and the HTTP connection becomes secured, at which time the hope of screwing with any of the data is lost.
The point is that the likelihood of this attack succeeding is basically non-existent. The user would have to ignore Windows' doomsday style warnings about certs, pass the Windows request for elevated administrator permissions (assuming you're using malicious software to directly poison the DNS cache or tell the system to use a malicious DNS server), then they'd have to ignore the giant red-screen, doomsday style warning in their browser (if their browser even allows it). It would be exceptionally difficult to pull of and would have minimal success even if you could.
As an aside, I really hope you're requesting this information for the sake of the good, not of actually attempting things like this. Tinkering around and learning these things can be fun and can aid in protecting users. Yes it would be perfectly ok to set up your own test network and hack it for fun and education, but doing and learning all this stuff to exploit people makes you a thug and a criminal and a disgrace to higher learning. I'm not saying you are this, I'm saying people who do that are. I hope you consider and weigh out these moral and philosophical questions in your adventure to obtain knowledge.
See also, for proof of browser protection from this issue.
Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. "