I've done a lot more work on this tonight and have the following information to submit:

Workaround
---------------
This isn't really a workaround as you won't have any keyring functionality but at least you can log in. 
1) Enable login by disabling the gnome keyring PAM Module:
# cp /etc/pam.d/gdm /etc/pam.d/gdm.old
* Edit /etc/pam.d/gdm and delete all lines which reference 'pam_gnome_keyring.so' (Expect to find 2 lines)
2) Restart GDM or Reboot
3) Log in and you should get in, but obviously without the Keyring features.

Reproduction
-----------------
The occurrence of this bug seems most prevalent on USB, Compact Flash (attached via IDE) and SCSI based boot devices.
1) Use the Workaround above to be able to log in as a user.
2) Open a terminal
3) Run:
# echo "<password>" | /usr/bin/gnome-keyring-manager -f --login
N.B. <password> would normally be the user's password it crashes regardless of what you give it.
4) The keyring daemon should now list it's environment variables, a few messasges, a warning and then will visibly die  with a SEGV.
NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option (as it gets called from the PAM module) will surpress all useful messages including the SEGV notification!! 

Debug
--------
I have attached gdb to gnome-keyring-manager and captured a full backtrace, register info and tread backtrace at the point of SEGV.  As I ran gdb pointed at the sources for keyring-daemon I have also captured 'list'.

On the console I get the following output:
>** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at /media/cdrom0
>** Message: adding removable location: volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at /
>
>** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already registered at: /
>
>Program received signal SIGSEGV, Segmentation fault.

It seems that gnome-keyring-daemon is being screwed up while it tries to probe the HAL about storage - This might explain the apparent correlation between boot disk type and whether one sees the bug.

We die in hal_device_property() at gkr-location.c:324

 323                 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
 324                 locvol->hal_volume = TRUE;

It seems that we might benefit from some kind of bounds check in this code as we seem to be taking it as gospel that 'locvol' will always return a valid address.

The SEGV happens while executing the instruction @ 0x080759c7 - This has been consistent throughout my old /var/log/messages files:

0x080759c2 <hal_device_property+834>:	call   0x804f8e0 <g_hash_table_lookup@plt>
0x080759c7 <hal_device_property+839>:	movl   $0x1,0x14(%eax)
0x080759ce <hal_device_property+846>:	jmp    0x80758a5 <hal_device_property+549>

So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, dereference it and write a gboolean there. This is fine for the first few volumes and $eax always = 0x80ca828 which I trust is the valid address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 (which helps me understand the fact the segfault is reported at '00000014' in /var/log/messages) - of course, 0x14 is not a vaild address.

The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, name) returned NULL. An educated guess tells me that NULL is probably a valid return if 'name' wasn't found in the hash, but more investigation needs to be done in whether a simply "if ( locvol != null)" check can be added or whether g_hash_table_lookup() should never return NULL.

Anyway, I've included the tee output of my gdb session which will hopefully be of use to someone who knows more about the linux HAL. 

If anyone wants me to gather any other information let me know, but I may need some instructions..