Understanding the DNS domain lookup mechanism

Will a DNS lookup for a subdomain, such as assets.example.com, be faster if the parent domain, example.com, has already been resolved?

Assuming that there is a caching server in the scene, yes. This is because in order to find an A record for anything in example.com., the nameservers for example.com. must be known. When the request for assets.example.com. is made the nameservers for example.com. should already be cached, and so the only query is for assets.example.com. itself.

I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?

These are typically caching or recursive nameservers. These do the hard work on your behalf (the multiple requests to traverse the tree) and then cache the result to speed up later queries for the same name.

Are all authoritative com nameservers, for example, exact mirrors, or would a resolver have to try each in turn?

Yes, they contain the same information. The resolver just has to find one which is actually working.

If the com TLD nameserver we're referred to does not know how to resolve example, is it right to say that's the end of the line: example.com cannot be resolved?

If the .com. nameserver responds and says example.com. does not exist, then the result is that the name does not exist. If the .com. nameserver doesn't respond to the query the resolver should try a different .com. nameserver.

When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain in the database used by the nameservers for that TLD? Does the registrar itself maintain "proxy" nameservers?

Correct. When you register the domain you provide NS records (and some A records if you need glue) to be inserted in the parent domain. The registrar doesn't necessarily run those nameservers itself, but have a mechanism to modify the database of those nameservers.

Most likely, your computer is configured to use a DNS server at your ISP. This is probably a caching name server. What that means is that it will cache hits (and in some cases misses) for some period of time (usually the TTL). If you query this name server for something in its cache, you're done. It will tell you the IP.

If it is a miss, it will query the top level name server (com, net, org, etc...) for the domain. In this example, it will ask COM where to find EXAMPLE.COM and COM will respond with the authoritative name server address (ip) for the EXAMPLE.COM domain. It will then ask that name server for what the IP for EXAMPLE.COM is and it will tell the caching name server which will tell you (this is an A record). Also, it will cache it in case someone else asks later.

If you are looking for ASSETS.EXAMPLE.COM the same thing happens but when you find the authoritative name server for EXAMPLE.COM you can ask it directly for ASSETS.EXAMPLE.COM and it will reply with either an A record (ip), CNAME, or NS record (there are other types also like AAAA for ipv6, MX for mail... but this will suffice for this example). If it gives you an A record, you are done. You have an IP. If it gives you an NS, it means that this other server is authoritative for ASSETS.EXAMPLE.COM and you should go ask that guy what the IP is.

CNAME is another type that starts this whole process over and isn't actually available on apex records (like example.com) anyway.