I hope you have a backup of that disk.
If your fsck is accepting directory entries like that, I must suspect a bug. So my first approach would be find a better version of fsck. Are your patches up to date? If you can find a patched version of fsck, try that.
The safest way out is a fair amount of work... Do a mkfs and reload all of the files.
There is, perhaps, a way to do what you want. I have never done it on Linux, but I have done it on HP-UX. So I am locating the similiar linux commands and guessing that they might work. Caution, I have never tried anything like this in linux.
You need to destroy that directory. A directory is actually a file and it has datablocks allocated to it. Each directory entry is a pair of items: a name and an inode number. Your directory has entries pointing to invalid inode numbers. To destroy that directory, use "ls -id /path/to/directory" to get the inode of that directory. Then destroy that inode and rerun fsck. The clri command is what I used on HP-UX and on linux, it is not a separate command, it is part of debugfs. So it goes something like:
1 find inode number of directory
2 umount /dev/sdb2
3 debugfs -w /dev/sdb2
4 at the debug prompt, clri 1234
5 at the debugfs prompt, quit
6 fsck -f /dev/sdb2
But I'm not gonna try that on my system... you first...