I just ran across something that could explain this.
I'm running Win7 x64.
Under the Arduino 1.0.1 environment, I get garbage serial data at 28.8kbps, but fine data at 115.2kbps.

I double checked the serial output with another terminal program (PuTTY, configured for "serial" on COM4).
It turns out the data coming out of my Arduino Uno board was fine.

Something's wrong with the serial monitor packaged with the Arduino 1.0.1 environment.
The following output was generated at one character per second, just counting 0 to 9 and recycling:
Data displayed by PuTTY: 012345678901234567890
Data displayed by Arduino 1.0.1 Serial Monitor: üÿüþüÿüÿýÿüÿüþüÿüÿýÿü
Both monitors were running at 28800bps.

And, this thread hasn't seen any traffic since August.  There's probably a better place for me to post about this...

The example code for LiquidCrystal::createChar() does not compile as written.
The call to lcd.write throws an error.
See: http://arduino.cc/en/Reference/LiquidCrystalCreateChar

I'm using Arduino environment v1.0, with avr-gcc-4.3.2.

Compile fails on lcd.write(0).
This is called after defining a custom character and loading it into the LCD with createChar(0,smiley).

Error is: "call of overloaded 'write(int)' is ambiguous".

Looking at the code in LiquidCrystal.cpp, I see the definition is LiquidCrystal::write(uint8_t value).

The call to lcd.write can be made to work with an explicit typecast: lcd.write( (uint8_t)0 );

Curiously, if I define a variable, and use it in the call, the example compiles happily:
   int zero = 0;  //or unsigned int zero = 0;  //OR even float zero = 0.0f;
   lcd.write(zero);

Calling with a float or double argument compiles as well: lcd.write(0.0); or lcd.write(0.0f); .

Curiouser, while calling lcd.write(0.0f); compiles, the two of these do NOT compile: lcd.write( (int)0 ); and lcd.write( (unsigned int)0 );.

And, thanks to the previous poster, TimeWaster, for pointing out the missing 8th line in the example character definition.  I completely overlooked the omission, myself.  But, somehow, that part of the code managed to compile and run smoothly...