It is certainly possible for a string to contain its own hash value, so it's even possible that $s_0 = s_1$.
And it's even possible to artificially construct functions that satisfy all the standard properties required of a cryptographic hash function (i.e. collision and first and second preimage resistance), but which hash an arbitrarily chosen string to a prefix of itself. All you need to do take any standard secure cryptographic hash function and redefine its output for that single arbitrarily chosen input, as in fgrieu's answer to this related question.
However, no examples of such strings are known for any cryptographic hash function that is widely used and currently believed to be secure, such as SHA-2 or SHA-3. Indeed, arguably, the ability to exhibit such a string would strongly suggest some kind of a weakness in the hash function, since finding such a string purely by brute force would be completely infeasible for any hash function with a reasonable output length (say, 256 bits or more).
Indeed, the same holds for longer cycles as well: as far as I know, for a random hash function $H$ with $n$-bit output, there's no way to find such cycles more efficiently than by using a generic cycle finding algorithm, all of which require at least $2^{n/2}$ evaluations of the hash function on average.
Finally, I should note that none of this necessarily has any relevance to whether or not Merkle DAGs or trees are well defined, as it's perfectly possible to define those structures in a way that allows two distinct nodes to have the same hash and/or the same children and/or content. For example, the definition of a Merkle tree currently given on Wikipedia reads:
[A] Merkle tree is a tree in which every leaf node is labelled with the hash of a data block, and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes.
While this definition is rather terse, and glosses over some important details (some of which are addressed later on the page), the key point is that under this definition a Merkle tree would remain a tree even if all the nodes happened to have the same label, since the labels have no effect on the graph structure of the tree!
Of course, a secure implementation of a Merkle tree should not allow an attacker to feasibly construct two nodes with different children and/or contents but the same label, at least not on the same level of the tree, since swapping one such node for the other would then allow a forgery. But even an insecure implementation that did allow that would still be well defined.
Conversely, even if you defined a Merkle tree (or DAG) in such a way that the connectivity of the tree was determined by the labels (i.e. such that a node $A$ was defined to be a child of node $B$ if and only if $B$'s label contained the hash of $A$'s label) then, as noted above, as long as you used a secure hash function with no known ways to find cycles faster than by brute force, you could still be practically certain that the resulting structure would indeed be acyclic.
A more serious conceptual issue with such a definition, of course, is that most non-leaf nodes of such trees would have an infinite — or at least a very, very large — number of possible children, simply because hash functions are non-injective and most hash values have infinitely many possible preimages, or nearly so. Of course, for a secure hash function, finding most of those preimages should be computationally infeasible, but theoretically they still exist.
In practice, to put such a definition on a solid conceptual footing, you'd probably have to restrict the valid node labels to only those appearing in some kind of a global database of known strings indexed by their hash, and then explicitly require that it be infeasible for an attacker to find a string outside the database that shares a hash value with any string in the database. Fortunately, this is a direct corollary of collision resistance (even assuming that the attacker can add strings to the database; otherwise second preimage resistance would be sufficient), and thus already (presumably) satisfied by any (presumably) secure cryptographic hash function.