There's an existing (in Leopard) bug with Secure Empty Trash. When it counts the number of items to be deleted, it fails to start the count at zero, so you wind up with some random number being added to the count. The random number is always the same number on a given computer, but may vary from one computer to another.
You can verify this for yourself by creating a couple of large files (on the order of tens of megabytes or so) and putting them in the trash, then doing a Secure Empty Trash.
Since you create the files yourself you can be sure there are no package considerations or anything like that at play.
For example:
head -c 20000000 /dev/random >bigfile
for i in a b c d; do cp bigfile ~/.Trash/bigfile$i; done
creates a 20mB file and puts 4 copies of it in your trash. (It takes a while to create the first file, so keep it around for later tests.) Then Secure Empty Trash.
On my machine, Secure Empty Trash takes about a half-second per megabyte, so each 20mB file takes ten seconds or so to delete. Finder delays 2 or 3 seconds before putting up the dialog, which lets you still see the last 8 seconds or so of the first file. After the four real files get deleted, the remaining spurious count goes rapidly to zero as Finder hears back from the helper app (Locum) that does the actual deleting. (It's probably Locum itself that is reporting the incorrect count.)
So, it looks like you've re-discovered a Leopard bug that wasn't quashed in Snow Leopard. I guess I get to report it again. (I described it as a cosmetic bug, which probably put it on the "fix the day before hell freezes" list. Ah, what the heck, it is a cosmetic bug.)
The reason for making the file so large is to put the emptying process in slow motion. Finder doesn't put up the progress window right away, so you won't be confident you saw the initial count until you see how slowly it changes.
