Cryptographically, this would be quite difficult to set up. After all, in order to generate certificate A, certificate B must already exist. And for B to be generated, C must already exist. For C to be generated, D must already exist, and for D to be generated, A must already exist. Such a "loop" would thus be very difficult to generate.
I wouldn't necessarily say impossible to make, simply because I am not qualified to make such an absolute statement, but I feel confident enough saying it would be very difficult to do so.
As for how any given system would react when encountering such a system...that is difficult to say, since I cannot find a way to produce and thus test it myself. I would assume that the system will throw an error, either recognizing that it has encountered a certificate twice, or via a maximum length limit. For example, the maximum certificate chain length limit in OpenSSL is 10 by default, according to the manual:
The default value for the maximum certificate chain size is 100kB (30kB on the 16-bit DOS platform). This should be sufficient for usual certificate chains (OpenSSL's default maximum chain length is 10, see SSL_CTX_set_verify(3), and certificates without special extensions have a typical size of 1-2kB).
Even if loops would not be recognized specifically, OpenSSL at least would throw an error after 10 iterations, as no root certificate would be found by then. Even if no specific check would be done, the application would keep allocating memory and would eventually crash, due to being unable to allocate more memory. Thus, the case that the application would keep running in the background, forever trying to check the validity of a certificate is not possible.
I hope this helps. Best regards, Tatyana