If you skip the padding and final non-padding characters then yes, each character should be equally likely. The output of SHA-256 is indistinguishable from random if you cannot guess the input. This also goes for iterations of the hash calculations over itself.
The final characters are not over just SHA-256 but are padded with zero characters. This is necessary since 256 is not a multiple of 6, and each character in the base 64 alphabet is encoding 6 bits. So the final 256 % 6 = 4 bits need to be encoded by adding two 0 bits (and possibly one
= sign for the padding).
Of course, this doesn't matter much since you'd still have all the entropy of the original password encoded into the base 64 representation, if you don't shorten the 43 or 44 characters of the base 64 hash of course; many password entry fields will not accept that many characters. Actually, you would be as secure if you use the hash without special characters. But that's often not accepted either.
Unfortunately, an attacker only has to deal with one additional hash calculation in your scheme. No salt or iteration count is added as would be in a good password hash algorithm. So while your assumption may be correct, the method of deriving a password hash - which this basically is - isn't.
Furthermore, your scheme may be vulnerable against somebody deliberately having your trying a password that will not generate passwords without symbols, as there is only a 1/64 chance of generating either one.
If you decide to shorten the hash or base 64 then you should not perform additional hashes over this shortened notation as somebody might be able to let you enter a cycle using the attack above. This chance is about zero if you keep hashing the full hash output of the previous generation.