SSL protects the confidentiality of your data if both the client (your machine) and the server (the Web site you are talking to) follow the protocol and are free from direct modifications. However, if (for instance) your enemy managed to install a root CA that he controls within your "trusted store" then he can produce fake certificates at will, for all Web sites that you contact. That is a Man-in-the-Middle attack: the attacker impersonates the server, so the data you send goes to the attacker, and what you see is what the attacker sends you; simultaneously, the attacker connects to the genuine server, posing as the normal client (you), and transfers data back and forth. So your requests ultimately go to the intended server, and its responses come back to you, and everything seems to go well, but the attacker gets to see all the unencrypted data.
Therefore, if the target site is out of reach of your enemy, and your computer is "clean" (bought outside of the country, including the OS, and no malware installed), then you might be fine. But these conditions are not so easy to achieve.
For emails, they are not transmitted with HTTPS. When you access your emails "with HTTPS", you are using your Web browser to access a Web-based interface on a server where your emails wait for you. But no HTTPS was in force when the said email transited from the sender's machine to that server. Emails hop from server to server and, as a rule, travel unprotected (some servers opportunistically apply some SSL protection, but this is not guaranteed, not necessarily done well, and emails are still stored unencrypted, if only transiently, on the intermediate servers). Therefore, if you read and write emails through a Web-based interface that you access only with HTTPS and that HTTPS is clean (see above) and the server which contains your mailbox is out of reach of your enemy and the people with which you exchange emails are also out of reach of your enemy, then it is conceivable that your enemy will not be able to read your incoming and outgoing email, nor guess with whom you are communicating. There again, these are big ifs...
Privacy is not confidentiality. For instance, when you connect to an HTTPS Web site, your enemy will not be able to see the data that you send to that site and what the site sends back (assuming a clean client and a clean server, as explained above). However, your enemy will be perfectly aware that you are exchanging data with that specific Web site. He will not when you connect, and he will see the size of all requests and responses, and can therefore make some good guesses as to what you are doing on the site. That's called traffic analysis. SSL ensures confidentiality and integrity, not "privacy" in a broader sense.
Also, if your enemy is a government, then chances are that he does not care at all about your actual password. Obtaining your password makes sense only for attackers who wish to impersonate you, connecting to your accounts on external servers. This leaves traces; spying agencies, as a rule, don't like that. Passive eavesdropping, or maybe traceless MitM, are more in character for them.
All of the above assumes that your enemy is extremely powerful but geographically limited; he can hijack telecommunication infrastructures at will throughout his country, but becomes powerless beyond the boundaries. This is a somewhat simplistic assumption. If the attacker is intent on unravelling your secrets, then he may also indulge in active hacking worldwide, trying to find and exploit vulnerabilities in external servers just like any amateur attacker.