I've written some code to just brute force tap configurations and starting values for small register sizes. So I have some values, rather than an analytic result. Of course the results are conditional on there not being any bugs in the code (https://github.com/bmm6o/MVFSR).
for width 4, max cycle length is 8for width 5, max cycle length is 10for width 6, max cycle length is 12for width 7, max cycle length is 14for width 8, max cycle length is 48for width 9, max cycle length is 48for width 10, max cycle length is 80for width 11, max cycle length is 108for width 12, max cycle length is 140for width 13, max cycle length is 270for width 14, max cycle length is 270for width 15, max cycle length is 270for width 16, max cycle length is 480for width 17, max cycle length is 752for width 18, max cycle length is 1520It can be risky to generalize from small values, but it does to seem to approximately double when the width increases by 2. This sequence is not present in the OEIS.
You've probably realized this, but your MVFSR evolves in a way such that most states have exactly 2 pre-images. I'm not sure how to use that to make a probabilistic estimate of the cycle length distribution, but it seems like it would be helpful.
For most cryptographic purposes, putting a lower bound on the maximum cycle length is not the most important question. Much more important is the minimum length, or at least a way to characterize and avoid short cycles. In that way, there is a serious problem with MVFSR. Under optimal tap selection, there are cycles of length just $2n$.
