Yeah, I'm not even sure where to start.
This is not something that will be likely to save you money. Anything other than a completely trivial amount of traffic will quickly saturate a residential cable/DSL connection. The major problem here is upload capacity, which isn't likely to be higher than 1mbps. You won't be able to server requests to more than a handful of users simultaneously -- any more than 6-8 people connected at once and it'll start slowing down and timing out.
There's also the power consumption -- on a commercial-grade rack server, this is non-trivial. Of course, you can simply use a consumer-grade box for this and it'll work (see also: Google), but I'm not sure what kind of hardware you're looking at on ebay so I want to cover the options.
Putting aside the why's and wherefore's, as requested, the actual mechanics of it are pretty straightforward. Set up a box, connect it to your network. Install Linux -- Ubuntu is as good a place as any to start, although you'll probably want to move to Slackware or something similar eventually. You'll do most of your configuration and maintenance via SSH, so you won't need a separate desk/keyboard/mouse/monitor for it.
Once you've got Linux up and running, install Apache and you're good.
The biggest problem is going to be the networking/routing. Ideally what you should be doing is getting a small subnet so that you have more than one IP available to you. That way you can avoid NAT in front of your server, and segregate the server from your home network. You can simply set up port forwarding on any residential router, but that's a bit of a hack. The ideal here would be a Cisco or similar router, plus an extra IP or two and probaly an hour or so configuring it (assuming you know what you're doing).
To Fugly, different hosts have different costs for a variety of reasons. For one, level of support varies. Some hosts allow or disallow scripting, some hosts offer different levels of tech support, some hosts will even take care of registration for you. On top of that is something that is pervasive on the business side of computers and networking, which is the service level agreement. Under an SLA, a host or service provider is contractually obligated to provide a predetermined level of reliability. Consider that even at 99% uptime, a server may be down for over 80 hours over the course of a year -- if that server represents your income, it's a big deal. The biggest providers offer 'five nines' SLA's (99.999% uptime), which requires a huge effort. Massive amounts of redundancy, multiple connections, multiple backups and the manpower as well. Those kinds of hosts cost a lot to use because the service costs a lot to offer.
So the short version is, you get what you pay for. If your website is about your dog Rex, having that kind of reliability might not be important. If it's how you support yourself and your family, then it becomes a different matter.
EDIT - You don't need separate hosting if you want a custom homepage. If you're really looking for that, you can just create the file on your desktop/laptop/whatever, and point your browser to it locally.
There really is no practical reason to have your own webserver. It's cost effective for very large operations who would pay thousands or millions per year to third party hosts, but I doubt anyone on this site (or even the site itself) has sufficient traffic to make that the case.
Also, that's not exactly how DNS works either. There is no one host (including the root name servers) that keeps track of every domain name in existence. If there were, simple updates would become a nightmare.
The whole thing is broken up into zones of authority, generally referred to simply as zones. A domain name actually reads right to left in terms of zone, which is why the (usually three letter) bit at the end is known as the top level domain or TLD. There are currently 13 root nameservers, which serve as pretty much the hub of the DNS system (and by extension, the internet as most people know it).
On every computer is a tool called a resolver. Whether you're running Mac, Linux, Windows or PalmOS on your cell phone, if it connects to the internet you have one. When you type a domain name into your browser, it gets handed off to the resolver, which goes to work. The resolver is essentially a pared down DNS server that's only able to make specific types of requests. It makes a non-recursive query to the name server specified when the network connection was established (usually via DHCP), which will then begin what's called a recursive query.
A non-recursive query is one that say 'I need an IP for this address, and I don't want anything else.' A recursive query says 'I need an IP for this address, but if you don't have one please tell me who might.'
The resolver will start at a root name server, with the TLD. When a domain name is registered, one of the things that occurs is that the IP address is added to the look-up table (known as a zone file) for the relevant TLD; thus, tfproject.org is registered with the .org root server. The root server will point the client towards the closest approximation. Sometimes it's the server in question, but often not. In this case, because my request was for
www.tfproject.org, the root name server will point me (or my DNS server, more specifically) to the name server that's authoritative for the tfproject.org zone. That server, in turn, should know the address for the server responsible for
www.tfproject.org. If there were a further subdomain (say,
www.boobies.tfproject.org) then there could be further levels of recursion.
DNS is enormously complex, and an issue all it's own, which is why I didn't initially touch it. If you want to run your own name server, you're going to be getting into a completely different can of worms.