Applying a transform on passwords before hashing them makes no direct harm to security as long as it is injective: two distinct passwords before apply the transform shall still be distinct once both are transformed. Your "character shifting" is fine for that if you do it properly (i.e. beware of transforming a byte of value 255 into a byte of value 0 which will "truncate" the password).
Indirectly, there is a bit of harm in that your extra transform is extra code, thus extra complexity, and complexity is always bad for security. Moreover, if the transform is computationally expensive, then it comes at odds with the iteration count used in PBKDF2/bcrypt (i.e. you have less CPU available, so you must use a lower iteration count).
A transform like the one you envision makes any good to the security only insofar as the attacker is not aware of it, i.e. the attacker did not do his homework. Basic, low-power attackers who just got lucky with a SQL injection attack may indeed lack the knowledge, but these attackers are not the scary ones. Your extra transform will not deter strong attackers, and that's strong attackers you should worry about.
Transforms applied after hashing have no influence whatsoever on security, except if you are using something like extra hashing, in which case you are just trying to build a custom hash function, which, as usual, is a bad idea. So don't do it. The proper way to use your CPU is not to waste it on voodoo character shifts and other rituals; instead, use your CPU to have a bcrypt/PBKDF2 iteration count as high as is tolerable for your overall application performance.