Before I started buying hardware, I would do some investigating with Performance Monitor to make sure that the disks are lagging. If the performance problems are caused by blocking by those "automated clients", you may find that performance on the new server isn't very much different than what you have now.
Edit #1:
I like to look at the Avg. Disk sec/transfer numbers. These are, essentially, a measure of the latency of the drive. I used to use the queue numbers, but you were supposed to divide them by the number of spindles in the RAID array. You don't always know that number, particularly with SAN storage, and the Microsoft Ninjas told me to give up on the queue depth numbers, back in 2002 or so.
(Normally, I watch the sec/transfer numbers, the read and writes per sec numbers (they give a nice feel for how the disk is going along) and the logical and physical page read values (helps to spot when some other, non-SQLServer thing is using the disk and when SQL is just scanning lots of data out of RAM). The last value is under the SQL counters, not the disk counters. And plain old processor utilzation, of course, for each available core (rather than "total").
With the Avg. Disk sec/tranfer values, I just look for average values below 50 ms for data drives and 20 ms for log drives. Note that your current set up has the OS and logs on the same spindles, meaning that they will fight for control of the drive heads and this will drive up your latencies.
Note that high read rates for databases may merely mean bad indexing. It's pretty hard to work through indexing issues on a web forum. With so much RAM in the new box, you may wind up storing almost all of the data in RAM. This will reduce the load on the disks, but you may find yourself with high processor utilization because SQL still needs to scan through all of that data; it's just in RAM, rather than on disk. Having it in RAM will be faster than on disk, but it's still going to be slower than a well-indexed database.
Also, I'd try to keep my data and tempdb on different sets of spindles because when you are doing heavy writes to tempdb, it generally means that you are doing heavy reads from the data (something like select * into #report from huge_table, or possibly use of distinct or group by for large result sets). If your application doesn't use tempdb too much it might not matter very much.
For a well tuned SQL Server, you shouldn't need to store the the entire database in RAM. I've got servers with 12 GB of RAM that server 100's of GB of data.
Also, you could probably save a little money by going with 10KRPM drives for the OS. Once SQL is up and running, it shouldn't touch the boot drive very much at all.
If I were in your spot, I'd be most worried about the lack of RAID redundancy with your current set up, followed by (probably) long backup times on that USB drive.
If I was stuck with that USB drive for a while, I might look at doing a FULL backup once a week, followed by DIFFERENTIAL backups once a day. Depending on how much of your data really changes on any given day, that ought to cut down on the amount of data you have to move to the USB drive.
