Is it safe to send clear usernames/passwords on a https connection to authenticate users?
Yes, this is the standard practice. Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security). As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the server. You don't gain anything by disguising the password before sending it as the server can not trust the client.
The only way that the information could get lost anyway is if the SSL connection was compromised and if the SSL connection was somehow compromised, the "disguised" token would still be all that is needed to access the account, so it does no good to protect the password further. (It does arguably provide a slight protection if they have used the same password on multiple accounts, but if they are doing that, they aren't particularly security conscious to begin with.)
As MyFreeWeb pointed out, there are also some elaborate systems that can use a challenge response to ensure that the password is held by the client, but these are really elaborate and not widely used at all. They also still don't provide a whole lot of added advantage as they only protect the password from being compromised on an actively hacked server.
Not necessarily.
You also need to ensure the following:
Your site is protected against cross-site request forgeries. Use Synchronizing Token Pattern.
Your site is protected against session fixation attacks. Change session id on login.
If using session cookies, that your entire site is HTTPS, not just the login URL, and that your session cookie is marked as secure and http only (no JavaScript access). Browser will send session cookie unencrypted if user types
http://yoursecuresite(in same browser session).You are using a recent protocol. SSL 1 and 2 are broken, and 3 might be too. Try to use TLS 1.3.
You are using a strong cipher.
You are not using HTTP compression (GZip) or TLS compression. If your site displays user input (like a search input), then I can figure out your CSRF tokens and bank account number if you're using compression.
Your server does not allow insecure client re-negotiation.
You are using a 2048-bit RSA key (or the equivalent for an EC key), and that no one else knows your private key.
You are using HSTS so browser goes direct to https even if user types http
You are using perfect forward secrecy so your historical communications are secure even if your private key is leaked
As long as you verify the certificate validity, this is perfectly fine and is done all the time.