Patch available here.
You can gain up to 510 bytes of on chip ram by disabling 3 serial ports. 
You can gain 8K of SRAM by changing to a '1284P chip too, and still have 2 serial ports if needed.
http://www.crossroadsfencing.com/BobuinoRev17/
PL & schematic here
There's a number of the bigger ATMega chips that allow external RAM to be connected as direct address RAM. All of the chips listed above are capable of running with -up to- 64K bytes at once when so augmented though I haven't done so myself. I bought SPI SRAM for external use on my UNO should I ever need it.
Add the Teensy++ 2.0 to the list of boards capable of using that trick.
Rugged Circuits sells bank select memory shields for the Arduino MEGA's. One lets you have 512KB in blocks. When used with smaller internal RAM chips, less of that gets wasted.
And you want to ditch 3 serial ports for how many bytes? Really?
Already doing that(RC Quad). This fix gives you more on-chip RAM.
for RC/Andy Brown see my xmem2 library here:
http://forum.arduino.cc/index.php?topic=160833.0
And yes, really, I have run into situations where I really did need that extra 510 bytes.
One other point too...
You can use this to disable all serial ports in the library and write your own, with smaller buffers. That allows you to still use all 4 ports. The benefit is that you do not have to modify the library or headers after this modification to do something like that. Currently you have to track down all these things. With one patch, everybody can gain RAM and eliminate bloat, external RAM or not!
I have patched iomxx0_1.h
No offense, but that's a TERRIBLE way to implement this sort of functionality; it's the equivalent of patching a system-level .h file (like stdtype.h) to get an optimization in a user-level program.
There have been requests to have the extra serial ports be removable in the past; I don't recall whether anyone actually implemented anything. Nothing should extend beyond the hardware/arduino/cores folder, though!
Here's a better patch - add the #undef lines to HardwareSerial.cpp in the indicated place.
(It should be simpler, but I guess it's not at the moment.)
// this next line disables the entire HardwareSerial.cpp,
// this is so I can support Attiny series and any other chip without a uart
#if defined(UBRRH) || defined(UBRR0H) || defined(UBRR1H) || defined(UBRR2H) || defined(UBRR3H)
/*
* remove uarts and their associated storage. That we don't use
*/
#undef UBRR1H
#undef UBRR2H
#undef UBRR3H
#undef USART1_UDRE_vect
#undef USART2_UDRE_vect
#undef USART3_UDRE_vect
#undef SIG_USART1_RECV
#undef SIG_USART2_RECV
#undef SIG_USART3_RECV
#undef USART1_RX_vect
#undef USART2_RX_vect
#undef USART3_RX_vect
#include "HardwareSerial.h"
That won't work for non-Arduino-IDE compiles...
The idea of my patch is to not disturb what the noobie to the AVR/Arduino expects.
It is something that is advanced, and disabled via passing the proper flags to GCC/G++. I do this with a Makefile.
That won't work for non-Arduino-IDE compiles...
Why do you think that? The storage you want to get rid of is in HardwareSerial.cpp, and that's where the patch should be as well. My change isn't at all Arduino specific. A batter patch would be to define new preprocessor symbols like "OMIT_UART1" and so on, but the changes would be more extensive.
The files in avr/lib/avr/include/avr/ are machine-generated and/or provided by Atmel. They should never be modified in a user's environment. Not ever. Period.
It is software.... Software is malleable. It is meant to be changed, patched and improved upon.
I would know this since back in the day (20 years or so ago) I wrote a libc and libm ]
I also do plan on passing this patch on to Atmel. Perhaps they can improve upon it, but I doubt that.