Is it secure to use so many iterations of AES-CBC as a KDF so that it's slow even using AES-NI? Note: This is not the same as Multiple iterations of AES for key derivation?.  

Almost everyone has AES-NI nowadays - when building a cryptographic application, is is possible to leverage this to create a kdf that is about as slow for the attacker to attempt a single key on a single CPU as it is for the user to derive one key?  

Also, is it possible to feed the last block of AES-CBC as the key of the next round of encryption over the rest of the ciphertext to make it memory-hard, and avoid encrypt-one-block-at-a-time-many-times attacks, as the entire ciphertext needs to be in memory?  

Essentially, key derivation would work something like this, just a lot more times:
Here's an answer that takes your question down a different path. RFC 2898, "PKCS #5: Password-Based Cryptography Specification: Version 2.0" is the document that defines the PBKDF2 function, in section 5.2.  Although PBDKF2 is normally instantiated with HMAC, the spec says that any pseudorandom function (PRF) may be used, with the implicit proviso that the PRF must accept variable-length keys (since the password is used as the key).

RFC 4615, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)" defines such a variable-length key PRF on top of AES-CMAC (RFC 4493):


  The AES-CMAC-PRF-128 algorithm is identical to AES-CMAC defined in [RFC4493] except that the 128-bit key length restriction is removed.


CMAC itself is a CBC-like mode that was designed to fix the shortcomings of the CBC MAC (which is only secure for fixed-length message spaces).

So by plugging in those reasonably standard components together you get an AES-based password-based KDF that is a bit different from your diagram but you might find close enough for your purposes.