Secure AES Key Generation via Salsa20? I am not rolling my own crypto or anything - just trying to learn about
the Dos and Don'ts of cryptography: specifically about AES encryption and
ways to generate keys for that.

As far as I've understand, one of the options when creating
cryptographically secure keys would be to gather entropy from
/dev/urandom and then feed that data through the Salsa20 cipher.

However I am not quite sure about the next steps, because that’s where search engines stop being useful to me.
From what I understand, using the output Salsa20 generates doesn’t seem to be secure enough to be used as key material as-is. 
If that's correct, what would be the "cryptographically" correct next step after getting the Salsa20 output?

Also, if you know of any relevant papers and are happy to share, they would be very welcome!
As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys.  Running these bytes through another CSPRNG is completely redundant. 


  As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and then feed that data through the Salsa20 cipher.


A symmetric cipher such as Salsa20 by itself is not the correct cryptographic primitive.  You need a CSPRNG (such as /dev/random).  


  But I am unsure about the next step, because that’s where search engines stop being useful to me. From what I understand, using the output Salsa20 generates doesn’t seem to be secure enough to be used as key material as-is. Am I correct? If, what would be the cryptographically correct next step after I've retrieved the Salsa20 output?


If you have some reason not to use dev/random (convenience, mistrust, etc), and you have some other strong (and I do mean strong, not just mouse-movements ala mega) source of entropy, then you should refer to one of the CSPRNGs defined in NIST Special Publication 800-90A.  You might be particularly interested in CTR_DRBG, which uses a block cipher internally (running in CTR mode, which is essentially a stream cipher like Salsa20).  You can find implementations of this in many languages.

Pro-tip: avoid Dual_EC_DRBG