What level of security does this offer, compared to, say, a traditional HTTPS login form using a username/password that's saved in the browser?
As you've gathered from other answers, HTTPS hides the actual request itself. The full URL is not sent when connecting to the server - the document part of the url is set as a request that looks something like this:
or more traditionally:
with the POST parameters sent later on in the HTTP request either in plain form or as part of a multipart mime body.
One consideration you have probably not thought of is that url access is typically logged by webservers, meaning at any point in time you'll have say 3 days' (adjust for your log retention policy) worth of username logins one grep away from your systems administrators. Whilst this is arguably immaterial since a modification to the application itself could dump out ordinary login credentials without much difficulty, there is now an added protection factor - do you back up your logs? What happens if these are stolen?
Worse, what happens if there is a way to manipulate your server to return the logs to an external client? This is a massive breach of security, but unlike returning a database of passwords which hopefully use good hashing technique to mitigate (and it is very much mitigate) the impact of this, a URL doesn't have the same protection - it is simply instant access to the account in question.
This is the server-side end of the client-side risk Thomas has already highlighted.