During a Q&A period at DEFCON this year, one member of the audience mentioned that we're using "fake salt" when concatenating a random value and a password before hashing. He defined "real salt" as something seen in the original Unix crypt implementation that changed how the algorithm ran, thus requiring different code to be used to crack each password and greatly troubling GPU attacks.

Is there any merit to the "real" and "fake" salt discussion?

The distinction is arbitrary. A salt-aware algorithm works by taking input data and scrambling it in various ways, and there is no method for inserting the salt which is more or less "fake" than any other.

Trying to devise a password processing algorithm which is efficient on a general purpose CPU but does not scale well on a GPU (or a custom FPGA or ASIC) is a real research topic. This is what scrypt is about, and arguably bcrypt already does a good job at it. The idea here is to use accesses in tables which are constantly modified; table access in RAM is something that general purpose CPU are good at, but which makes things difficult for GPU (they can do it, but not with as full parallelism as what is usually obtained with a GPU).
