According to this comment on a GitHub request for a streaming implementation for digests, ciphers and signature algorithms it is seemingly not possible to start hashing the data before the signature can be generated.
Is it possible to preprocess (i.e., hash) data in any way and if so, is this dependent on - for instance - the availability of the private key?
What about verification?
Well, to implement EdDSA in a 'streaming' mode, there are two options:
You could do 'prehashing'; that is, hashing the message and then signing the hash.
You could modify how $R$ is generated - instead, on relying on SHAKE256(dom(F, C) || prefix || M, 114), you could generate that value randomly.
Neither option is perfect. With prehashing, the verifier has to know you're doing this (rather than directly signing the data).
As for modifying how $R$ is generated (which is interoperable with standard verifiers), you need to understand why EdDSA was specified that way. Traditional ECDSA implementations relied very heavily on their randomness sources when signing; if they generated two different signatures with the same $R$, they just leaked the private key. When they designed EdDSA, they didn't want to leave that foot gun in place, and so they designed a system so that for any two different messages, unrelated $R$ values will be used.
By changing how $R$ is generated, you are putting that foot gun back into place. It is safe if your source of randomness is good - however, you need to keep that in mind (and if you're not absolutely convinced you can guarantee that, well, perhaps prehashing is your best option)
As indicated in the comments the standard RFC-8032 on EdDSA contains a method called HashEdDSA to pre-hash the message using the $\text{PH}$ function. This is a tactic often used for e.g. hash lists or trees where a set of hashes is hashed as part of the signature, but here it is standardized explicitly to allow hashing with a single hash function before signature generation.
The HashEdDSA for curve Ed25519 is named Ed25519ph. Ed25519ph uses SHA-512 both for the pre-hash function $\text{PH}$ as well as the inner hash & signing functions that are always used. EdDSA for the goldi-locks curve Ed448 is named Ed448ph. Ed448ph does use SHAKE256 so it does officially answer the original question which just mentioned SHAKE.
Note that the standardization of HashEdDSA do trail most implementations of the EdDSA algorithm, so the various libraries may not include support for HashEdDSA.
That however means that the message simply needs to be hashed before it is used within the EdDSA implementation. As such it requires a small update of those libraries that do not yet support it.
If the libraries only offer EdDSA then this may have a small impact on the agility of the software that uses the library: prehashing the message in code is more complex than simply substituting one algorithm by another after all.