Your everyday experience shouldn't get affected, hopefully. Wayland removes a lot of legacy from X, but their end result is pretty much the same, "display some stuff on my screen". And XWayland should assure this, since you'll be able to run applications that don't support X on Wayland in a seamless way. Most applications use some toolkit anyway (gtk, qt) that are getting ported to Wayland, so the author of that applications shouldn't do any changes to make it work on Wayland (beside recompiling it).
At best, Wayland should be lighter than X, and it should fix tearing if you have some now (but this is already fixed by modern wm, at least on my computer).
One of the biggest change that you shouldn't notice is security, X has tons of holes (every application can read/write into another application), which wayland fix (see here for more: http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and...).
Same for Mir (but I dunno about the security issues that Wayland fixes), but upstream doesn't seems willing to accept Mir-specific patches, so Canonical might end with having to patch applications/toolkit/drivers downstream (but the user shouldn't notice any difference anyway).
Gnome should ship with Wayland considered as stable with 3.14, and (as far as I know), there's no plain to ship KDE on Wayland before KDE5. XWayland still need works, and without it no distro will ship Wayland. The proprietary drivers still need to come out (Nvidia might be at work on them already, but for all we know it might still be just some drawing on a blackboard - and let's not forget about AMD, that will probably take quite a bit of time).
Also "normal" distro (Mint, openSUSE, Fedora...) will probably take their time as well to ensure that everything is working. I'd expect to see some kind of experimental preview, then a version with support to both (but with the default still being X) and then a version with Wayland (and an X failback).
Probably I'm just being negative here, and if everything happens faster than how I think it will, then great! Also, probably just a generic "years" feels too much, my expected timeframe is/was 2-3 years.
See:
* http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Sche...
* http://blog.martin-graesslin.com/blog/2014/03/kde5-and-wayla...
There are commits [1] on the Chrome tree designed to get Chrome working on Wayland, but for those commits to reach significant numbers of users will require the cooperation or at least the "non-interference" of the employer of most of the Chrome devs -- which is at this time an unknown.
Firefox Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627699
You can install a build on Fedora via this copr (like a PPA for Fedora): http://copr.fedoraproject.org/coprs/stransky/FirefoxGtk3/
AFAIK Fedora is planning to ship Wayland in version 21, scheduled for release later this year. Probably not as default, but still.
After that period of introduction though, what you should be able to expect is better ram/cpu usage for the display server (wayland's architecture makes it much easier to offload everything to the GPU, X has some warts that makes that very hard). Based on what I've seen there should also be better support for tear-free video playback and eventually possibly even proper NVIDIA Optimus support (and AMD's version) which should help a lot of people with battery life.
That covers most cases, but there are others. Some toolkits won't be ported immediately. Some applications use functionality that's tied to X even if they use a toolkit that supports Wayland. The compatibility solution is XWayland. This is a simple X server that can be launched on demand, allocates a Wayland buffer per X window and then renders into that buffer (this is similar to how XQuartz works on OS X, except with more on-demand activation).
So, other than bugs, things should be pretty transparent. There'll probably be some slight awkwardness in cross-X/Wayland interactions (clipboard semantics may not be identical, drag and drop behaviour may vary, that kind of thing) but nothing that most people will notice.
Mir ought to be in the same state, but right now XMir doesn't support the same kind of rootless behaviour as XWayland - instead, X applications all run inside one separate window. I'd expect that to be fixed before Mir is used as the default environment anywhere. Mir is also lagging behind Wayland in terms of getting upstream toolkit support - again I'd expect this to be something that's sorted out in future.