Say you were to generate a 512 bit AES key, then encrypted a message by running it through AES CTR 256 twice, with the first and last parts of the key respectively.
Would it be as secure as modifying an AES implementation to increase the rounds to 28?
Cryptographic security is not a one-dimensional spectrum. Increasing the key size increases keyspace, which is the maximum number of possible keys that must be iterated through to complete a brute force attack. Increasing rounds, on the other hand, reduces the chances that novel cryptanalysis, which allows an attacker to break the cipher faster than brute force, will be successfully applied to the cipher.
Cascaded encryption, even with stream ciphers, is vulnerable to a meet-in-the-middle attack, which reduces the effective keyspace from 512 bits to 384 bits. It is further reduced because layered stream ciphers commute (the order of the stream ciphers doesn't matter, so two keys whose first and second halves are swapped are equivalent). However, it will not reduce security and the keyspace will be larger than 256 bits, even if it won't reach the theoretical 512-bit maximum that you want. Regardless, no one is going to brute force a 256-bit key and doubling it to practically improve security is a quixotic endeavor.
In order to avoid the meet-in-the-middle attack, you would need to redefine AES to use a 512-bit key. This would require a deeper knowledge of the Rijndael key schedule, but if you successfully do it, you would be able to take full advantage of the larger key, even if it's unnecessary. This is a lot more difficult than just increasing the number of rounds though, and without heavy analysis, something may break.
Increasing the rounds has a bigger effect, although it does not increase the keyspace at all. Increasing the rounds from 14 to 28 would drastically improve security. But that doesn't mean you should do it! It's not necessary, because 14 rounds is already considered sufficient. You'd be decreasing performance while increasing the security from "excessive" to "even more excessive". There's no reason to do it. If you did have to, you would need to make sure you adjust the round constants correctly through $\text{rcon}$. Rijndael is able to generate up to 255 extra round keys, in theory, without modifying the key schedule.
AES with 256-bit keys was defined with 14 rounds (12 and 10 rounds for AES defined with 192 and 128-bit keys, respectively). This number was selected based on extensive analysis from many experts all over the world. During the AES selection process by NIST, the best attack was found to only penetrate 6 rounds. The designers of the cipher (called Rijndael at the time) decided to add four extra rounds at a minimum as a "security margin" to hedge against future attacks. It has held up extremely well so far.
The first question you should ask yourself is what you are trying to protect against. AES-256 is even considered secure against quantum computers. Certainly a brute force attack is already far out of reach. So if AES breaks it is likely because the algorithm is broken. In that case neither of your schemes may save you; you would have been better off using an additional Feistel cipher or one based on a sponge such as the one used in Keccak.
Yes, AES-512 as you specified it would probably be as secure as an increase of the rounds to 28, if you assume that the subkey derivation of your new variant of AES doesn't have a particular property that makes it harder to crack. I presume here that you also use the larger key size for the 28 round version, of course. The problem is that you cannot just double the number of rounds without inputting new subkeys for each round in that version. How these are calculated isn't specified. However, if your subkey derivation protects against meet in the middle attacks then the 28 round version is probably more secure.
Of course, it is extremely wasteful to use 28 rounds. A good design should be able to use e.g. 18 rounds for AES-512 (as AES-128 uses 10 and AES-256 uses 14). Furthermore it seems weird to double the number of rounds and keep the blocksize at 128 bits; the block size of AES is probably more detrimental to practical security than the key size.
Although double CTR is considered secure, you would probably have some issues using the double key scheme for other operations such as MAC.
Finally, obviously you've introduced $2^{256}$ weak keys in your double-AES scheme. If the first and second key are identical then the plaintext will not be encrypted at all. With a key space of 512 bits that's not a huge issue, but generally you want to avoid weak keys altogether.
