Here I how I understand it(forget about db input sanitizing, and hashing/salting for now):

1. visitor goes to login page for the domain.
2. login page retrieves client cookies for the domain.
3. if no cookies, the login page completes loading and gives user/pass form text boxes and button which user fills out and submits to login page
4. login page queries website DB, finds username and validates the correct password
5. login page generates, say a random 100 character long a-Z & 0-9 string to use as cookie, inserts into DB cookies table, associates with foreign key of user account
6. login page pushes cookie to user after setting domain, cookie name/value, timeout, etc other cookie settings
7. login page redirects client to some User resource page
8. client opens user resource page, which retrieves client cookies for the domain.
9. client provides the cookie it was just given by login page
10. User resource page looks for this particular 100 character string of text in the cookies DB table, find it, determines user ID associated with it, and then provides user-specific into to the client. voila

Is that how it works in practice?  if not, Is what I describe not feasable/secure/etc?

Finally, what is a "session"?

Yes, this is generally how a session key / access token works.

A session is essentially the window of time of a given authentication. A lot of sites will have an 'unlimited' session key, or basically a key / token that never expires. But others will tag a session key / access token with an expiration date. Some will make this expiration date a hard date, while others may decide to 'refresh' the date whenever the session key is used (not idle).

Encrypting the data connection is the primary method of securing the session key / access token in transit (e.g. https only).

You also need to test the given site to mitigate any Cross Site Scripting vulnerabilities to prevent key / token theft.

Using long / complex session keys are good to prevent key 'guessing' (use in combination with expiring keys).

You can also constantly change the session key on behalf of the user without requiring a re-auth.

Always set secure and httponly cookie attributes.

Also, there are many session management frameworks already available. Don't bother trying to invent your own. You will never be as smart nor have the time to test your own code compared to these supported frameworks. If you just want to roll your own to learn, no big deal but wouldn't go to production with it.

this was my first thought as well.