URLs are meant to specify three things - a protocol, a host, and the location of a resource on that host - NOT just a host. Not all protocols use URLs or make sense with them, SSH being one of them (SFTP being different, of course).
What you are really asking is how can you give each computer on your network its own externally resolvable domain name.
You are likely a standard residental ISP customer with a single IP given to you by your ISP, with your machines on a private IP range LAN and use a NAT router. So, as aforementioned, you cannot do what your university did - what your university did depends on each machine having its own public IP address, which is possible for universities as some have large IP blocks assigned to them. This isn't going to happen for you as a residential ISP customer, though.
Nothing is stopping you from running your own DNS server at home, telling your router to give out your private DNS server as "the" DNS server and assigning each machine on your network an internally accessible domain name using it. It will work beautifully - within your house (until you want to resolve an external host such as google.com - unless you set up DNS forwarders, but that's another subject).
I have never been too clear on the DHCP "domain" option myself but it doesn't and cannot affect anything reachable from outside your network in this scenario.
For your single public IP you can get a domain name for it, and there are providers such as no-ip.com that give you a free one - you do need to run a client somewhere on your network that updates the provider with changes in your public IP address. I believe no-ip.com lets you have up to two domains pointing to any machine you like. But, if you point them both to your single public IP, they are really pointing to the same place, because domains do not have any concept beyond "this string = this IP address."
So, with things like SSH you are stuck with port forwarding. You have to tell your router to forward incoming traffic on something like TCP 1000 to your first workstaiton's private IP, port 22, and then TCP 1001 to your second workstation's private IP, port 22.
With HTTP, many web servers can do a thing called "reverse proxying" where one URL is actually a front end to a different webserver. So, if you are running a webserver on workstation 1 (i.e. http://mypublicname.no-ip.invalid) - you can configure Apache to reverse proxy something like the directory "workstation2" to a second workstation also running Apache. So then, the end result is that http://mypublicname.no-ip.invalid talks to the webserver on workstation 1, and http://mypublicname.no-ip.invalid/workstation2 tells the webserver on workstation 1 to talk to the webserver on workstation 2, and forward back the result to you. This is protocol specific and I'm not sure too much other than HTTP can be "reverse proxied." You couldn't RDP over an HTTP reverse proxy unless you had some scripts or Apache plugins supporting that.
You also may want to look into an SSL VPN such as Adito aka OpenVPN ALS. It lets you set up tunnels and provides a very nice interface for doing so. It's very convenient and worth the trouble to go through setting up.