Actually, that turns out that it's sometimes a useful way of implementing CBC mode (at least, with the understanding that you don't send the value you have labeled 'Initialization Vector', but instead the first cipherblock you generate will be sent to the decryptor as the CBC mode IV, and the rest of the cipherblocks will be sent to the ciphertext.
It is easy to see that if the decryptor uses the standard CBC decryption process with the provided IV and ciphertext, he'll get the plaintext.
So, why is this useful? Well, one requirement for CBC mode is that the IV be unpredictable (specifically, unpredictable to someone who doesn't know the key; if they know the key, they don't need to predict IVs to verify potential plaintext blocks). With the standard CBC mode implementation, you are given the responsibility of generating unpredictable values, which is not especially cheap.
However, with your construction, it turns out that we no longer require that the first block (that is, the one you labeled 'Initialization Vector') be unpredictable; it is sufficient that it just be unique - after it passes through the AES function, it'll become unpredictable. Hence, it is sufficient that it can be a counter, which is a lot cheaper than an unpredictable value.
However, you'll say, you perform another CBC mode block (which involves another AES block operation); doesn't that increase the cost? Well, sometimes, it doesn't - specifically, if you have some encryption hardware that performs a CBC mode encryption as a primitive, then the cost for encryption one additional block is usually fairly minimal (and certainly a lot cheaper than a side operation to generate an unpredictable value).
So, if you are in this specific scenario, yes, it can be a nice optimization.