The title says it all, really. I'm Alice, and I want to login to Gmail's web interface through my browser. Ike, the internet service provider, and Adam, the local network administrator, would like to know what my Gmail email address (username) is. Is there any conceivable way for things to happen so that either one of them could possibly learn it?
For your average home user, services like GMail (that are run over TLS) would not leak information like the username to the ISP or network administrator.
If you're using a machine that is also administered by the LAN administrator (e.g., a work computer attached to a domain run by the company), then you have to assume they can read anything you do on it. They could have software to log your activity (browsing and/or keystrokes), they could have installed extra SSL certificates that allow them to MITM your connection to GMail (or any other site).
If you believe your computer has not been tampered with and is not under the control of someone you don't trust (i.e., the LAN admin doesn't control your machine), then you can connect to GMail over https. (At this point, the LAN admin is equivalent to an attacker on the internet.) Ensure that you connect to https://mail.google.com with a valid certificate, and then all your traffic between your computer and the GMail servers are encrypted. This would include all information about your account, including the username with which you are logged in.
To complement @David's and @Steve's answers:
If the attacker ("Adam", in your case) has administrative access to your machine, then he can learn all your secrets. Installing an extra root CA, under his control, to run routine MitM interception on your SSL connections is a popular tools for honest (but nosy) sysadmins: it is a one-time installation which won't be jeopardized by software updates, and won't incur compatibility issues with other software such as antivirus. However, a nosier sysadmin who wants his spying to remain discreet has a lot of other options, such as installing keyloggers, screen capture tools, and generally plundering the data right from the RAM of the machine.
If the attacker does not have access to your machine's innards, then he should be kept out of your SSL exchanges. He will still be able to notice when you connect to Gmail, and can observe the exact size of the data elements exchanged with Gmail. He can probably work out the length (in characters) of your Gmail address.
As @Steve observes, a Gmail address is not designed to be a secret, and will leak in many places. In any case, as an email address, it is necessarily shared with other people (those who send emails to you), and therefore cannot be considered truly secret.
If you use Google+ (indexed by your email address), the evil sysadmin will notice your activity, and may correlate it with visible activity on some candidate Google+ accounts. After all, if he is after you, then he is interested in you, and may as well show some dedication and track you competently.
As David says, the provider of your network usually can't see data passed over https connections.
However, your Gmail address is not necessarily passed only over https connections. For example, if you log into StackExchange using your secret Gmail account and visit the http (not https) version of your user profile page, then your Gmail address is sent to you unsecured in the contents of that page. The provider of your network connection could then see it. The same may be true of other sites that use https for OAuth login but not for all traffic.
Also, as user49372 points out, if Adam is willing to mount an active man-in-the-middle attack, and if you log into StackExchange using your secret Gmail address, he could inject stuff into your normal http traffic that would redirect your browser to the http version of your StackExchange profile page.
So yes, there are conceivable ways Adam or Ike could learn it even assuming that they can't interfere with your machine or otherwise overcome the security provided by https.
The one answer I haven't seen given here is one that relates to corporate environments, like mine, where the corporate machines access the 'net through a filter/proxy, which allows the "administrators" to inspect SSL traffic, by forcing client machines to trust the webfilter/webproxy's SSL certificate. The webfilter/webproxy then impersonates the client machine to Google (or any other online service), downloads the content, and then passes it back to the client machine by impersonating Google (or any other online service) to the client.
This is, in effect, a MITM attack, but it's common enough that I think it bears mentioning, specifically.
If you access the 'net through a proxy or filter that's setup to inspect SSL traffic, then to your administrators, anything done over https is viewable as if it was sent in plaintext.