Certainly you could turn your wordlist into a regexp that matches any string of concatenated words, something like:
There even exist tools to optimize such regexps, such as the Regexp::Assemble module for Perl.
However, I would not generally recommend this approach for identifying correctly decrypted plaintext.
For one thing, even a single misspelling or unrecognized word in the plaintext can cause the match to fail. For another, as you increase the size of the dictionary to reduce the chance of such mismatches, it becomes more and more likely that an incorrectly decrypted text will nonetheless match just because it happens to equal a meaningless string of obscure words.
Basically, the problem is that the regexp cannot distinguish common words like "the" from obscure but valid ones like "adz", not can it distinguish reasonable word combinations like "a quick brown fox" from nonsensical ones like "bulks fey hoof re".
As an extreme example, if your wordlist happens to include all single letters as valid words (as some commonly used ones do), then the resulting regexp will match any string of letters!
Instead, what I'd recommend you to use is frequency analysis. To decrypt a simple Caesar cipher, it's usually enough to compare the single letter frequencies of the candidate decryption to those in typical English text, but for more complex ciphers, it's usually better to look at the frequencies of bigrams (i.e. pairs of adjacent letters) or longer n-grams.
The advantage of n-gram frequency analysis is that it provides a measure of statistical and context awareness, such that a substring like "thenext" is rated as more likely than either "irkteal" or "xheettn", while still remaining fairly robust against things like jargon or minor spelling variations. That said, there are a few issues to keep in mind when applying it:
The choice of source corpus does matter somewhat, since different words are common in different kinds of text. For example, I once tried to compile an n-gram list from a Wikipedia database dump and found some rather unexpected peaks for stuff like the 5-gram "ation", presumably due to the large number of formulaic tables listing the "location" and/or "population" of things. Properly applied frequency analysis is fairly robust against such variations, but it's still work keeping in mind.
In particular, never use a word list as your (sole) source of n-gram data. A word list lists each word once, no matter how common or rare it is in typical English text, and it also doesn't give any useful information about the frequencies of n-grams spanning word boundaries. (That said, using a dictionary as part of your source data, along with a large corpus of normal English text, may be useful to ensure that even rare n-grams are included.)
Especially for longer n-grams, there's a risk of overfitting: if the plaintext includes an n-gram that never appears in your source corpus, a naïve n-gram analysis would assign it a zero likelihood of being correct. There are statistical techniques that can help reduce this effect, such as additive smoothing, but applying them effectively is something of an art.
Ps. All that said, your regexp approach might be useful in some cases, e.g. for very short messages, for which frequency analysis can perform poorly. Even in those cases, however, I'd suggest using the regexp only as a first step to break the message into words, and then scoring the results based on their frequency and/or likelihood of co-occurrence. (For example, while "the" is a very common word, "the the" is much less common, at least unless the message is about British post-punk bands.)
It would also be a good idea to keep in mind that there might be more than one way to split single string into words; if you don't want to consider all possible matches (which could be slow), you should at least order the words in your regexp in descending order of frequency (which, under most regexp engines, will ensure that the more common words will be considered first).