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 8
for width 5, max cycle length is 10
for width 6, max cycle length is 12
for width 7, max cycle length is 14
for width 8, max cycle length is 48
for width 9, max cycle length is 48
for width 10, max cycle length is 80
for width 11, max cycle length is 108
for width 12, max cycle length is 140
for width 13, max cycle length is 270
for width 14, max cycle length is 270
for width 15, max cycle length is 270
for width 16, max cycle length is 480
for width 17, max cycle length is 752
for width 18, max cycle length is 1520
It 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$.