If your database is at all write intensive, use RAID 10, not RAID 6. With really fast, really great SAS disks.
Buy a bigger chassis than you need so you can grow in to it. I recently added a quad core to my production database server- and I can tell you, for once in my career I was really glad I bought the dual socket motherboard even though I only needed four cores to start. Having CPU utilization go from 60% average with long spikes at 100% to 30% average with only rare 100% spikes had a huge impact on our performance. Not having to completely migrate from one machine to another to get this was truly awesome - popping another chip in the extra socket took about 20 minutes. As for RAM; put in as much as the machine can take.
As a note, our production system uses SAS, our development system uses SATA. We can definitely feel and quantify the difference; queries that might need 1.5 seconds on our loaded production machine might take 3 seconds on our non-loaded development server. This is definitely anecdotal, of course, and there are other differences; but we've noticed that IO is definitely the killer. 1.5 seconds is not a big deal, right? Except in production that's a 1.5 second difference * x users * y requests per hour.
One more thought on IO: we were careful to set up our biggest most often used tables to be on filegroups with multiple files in them. One of the performance enhancements of this is that SQL will thread requests to each file in the filegroup - so if BigOverUsedTable is on FileGroup1 and FileGroup1 has four files in it and your DB has 8 cores, it will actually use four cores to do "select big number crunching nasty query from BigOverUsedTable" - whereas otherwise, it will only use one CPU. We got this idea from this MSDN article:
"Filegroups use parallel threads to improve data access. When a table is accessed sequentially, the system creates a separate thread for each file in parallel. When the system performs a table scan for a table in a filegroup with four files, it uses four separate threads to read the data in parallel. In general, using multiple files on separate disks improves performance. Too many files in a filegroup can cause too many parallel threads and create bottlenecks."
We have four files in our filegroup on an 8 core machine due to this advice. It's working out well.