generate salt encrypt it with AES using user's password as key save
the encrypted salt and hash
You could do this and it would be an effective salt, however it wouldn't actually be any more secure than just using a regular salt.
Let's consider two attack vectors:
Obviously we don't want two users with the same password to have the same hashed password. To prevent this we use a random salt and assume that the probability of two users with the same password and the same randomly generated salt is effectively 0.
However, if two users happen to have the same password and coincidentally the same salt then they will have the same hash regardless of whether the salt is encrypted with their password or not encrypted at all. Therefore, by encrypting the salt you're not making it any less likely that a collision will occur in the salt. The only factors which do make it less likely is the quality of the random values used for the salt and the number of bits.
Brute force attacks
If an attacker is trying a brute force attack and you've encrypted the salt the only extra step they have to do is decrypt the stored salt each iteration and use that to produce the hash they then compared to the hashed password to see if they have a match.
This does require marginally more effort for an attacker, but when it comes to cryptography making something take only two or three times longer isn't significant. If brute forcing a password now takes 3 days instead of 2 you haven't really made it materially more secure. If you're trying to make something secure you want it to take 5000 years instead of 2 days.
If you want to slow down brute force attacks you'd be better off iterating your hashing process tens of thousands of times or using a hash function which is specifically designed to be computationally slow.