This scheme looks clever, but it isn't.

Salts are usually stored in cleartext. And they serve one purpose - to restrict the usability of precomputed hash tables. There is also the side-effect that no two hashes computed for two different user accounts will be the same.

By storing a portion of the password as a salt, you are decreasing the security posture of the application, and also complicating matters:

 * By using the password fragment as a salt, you would store a portion of the password in cleartext. If it is 8 bits, I would consider that the entropy associated with the password is reduced by a *minimum* of 8 bits. After all, you've made an attacker's work easier. Note that 8 bits is a minimum value for the decrease in  entropy. If the attacker knows that the user uses a repetition of the first 8 bits as the password, the effective entropy is 0.
 * Using the first 8 bits of the password as the salt is in itself a poor decision, compared to using the last 8 bits, not that the latter is a good decision. It so happens that under the Shannon model for computing entropy of a password, the entropy per bit reduces as the length of the password increases. If you are using the first n bits as the salt, then you are weakening the password further, as the Shannon model works on the premise that "if the first n bit is known, then how well can anyone guess the other bits". In simpler words, if an attacker is allowed to know a portion of the password in cleartext, it is easier for him to deduce the other unknown portion, because the contents of the password are not truly random.
 * Now that you've stored the password fragment in cleartext, you will need to encrypt it. That sounds easy, except that keys have to associated with a management lifecycle where you need to issue them, protect them, and discard them after a particular period; getting of this right is certainly not as easy as using a secure PRNG to generate the salt and storing this random sequence of bits in the clear.