If that were true, no-one would have felt the need to invent the term "epic"!
The reality in an substantial product is that a statement like "we want to offer customers a voucher giving them £20 off their first purchase" simply cannot be broken into 2 week stories that in themselves each deliver customer value.
Breaking it down:
1. We've got to change our user sign-up process so that it issues a £20 voucher to every sign-up
2. And we need to change our entire checkout process to allow for users with vouchers that they want to spend
3. Not to mention we need our invoicing/accounting systems to understand what a voucher is and how to record it (and the spending of it) financially
4. We want vouchers to have an expiry, so they don't remain a liability on our books forever
5. And we want to limit how many vouchers we issue in a week, as some protection against abuse
Now, I can instantly see that points 4 and 5 are not "MVP" - we can launch, and then add these stories in later iterations. But you can't deliver points 1 or 2 to customers, you have to have built 1, 2 and 3 before there's something fit to launch.
Okay, so you can say that 1, 2 & 3 are all one story. Yeah, I agree. That still doesn't mean they can be delivered in less than 6 weeks. I know because we just did it (or something very like it). So whether you call it one big story, or a 3 story epic, that's just semantics. It's still 6 weeks before there's something that can be given to customers.
But as you can see, we certainly had something to show stakeholders at every 2 week interval.
To me, this is the reality more often than not with many substantial new features. So when stakeholders say "we want to give new customers a £20 voucher to spend, when can we have that?" our engineer team need a way of giving back something more than the tired agile cliche "it will be done when it's done" - then need to be able to say "we'll get that done in about 6 weeks."