Problem Solved
At 0100 local time, I awoke with an epiphany. I loaded the special character immediately after initialization of the display and before any screen commands. That helped, but wasn't perfect. After more monkeying around, here is what I found to make it work:
1) Added an extra 100 mS delay after initialization of the LCD (total delay 200 msecs). The other delays I had inserted appear to be unnecessary.
2) Immediately called the custom character definition.
3) Changed the character definition to use only the lower 5 bits, i.e., the high 3 bits that define line are not needed and seem to be part of the problem.
I have tried so many things since noon today that it is hard to say exactly the effect of each. I don't intend to test all the possible combinations. Nevertheless, here are some general impressions.
Regarding the use of only the 5 lower bits for definition, I had actually tried doing that early on, and when it didn't work, I went to the full 8-bit definition, which seemed to help. I got the character, but also got the noise and extra pixels. I guess the high three bits may not truly be ignored.
After reading the example code (Basic), I wondered whether immediately displaying the character was needed. When an immediate display was added to the definition, the screen filled with the character. Even with the extra delay, that still happens. Whether that is a product of the rest of my program or a function of the display will remain unknown.
Thank you all for the input. The problem was multifactorial, and those always waste a lot of time. Not being able to simulate the display was a pain.
John
Edit#2:
@MrRB : Yes, I tried not sending the last row early. Got no character.
@SHC (stochastic hill climbing): What if in putting together incremental randomly selected improvements, an early improvement actually blocks the final and best solution?