Add at the end of the last demo level a script that displays "demo ends here" message and drops you into the main menu, then rip off from the package data not used in demo levels, upload, done. An hour of work for a single guy.
For more open game there is more work, because you can have multiple points to create demo cutoff, but it's still up to one week of work for a single dev and lets say two testers, not a big deal for a project developped for 3 years by 100 people.
If we're talking about PC games, it incredibly depends on how the title is structured. It's not as easy as implementing a 'demo cutoff', even if a game is very linear. There's lots of considerations to be made, and cutting off pieces of content and features can have consequences you could never predict. If your code (and content!) is very modular and you can take out bits and pieces of it without the whole thing falling apart, then sure, it's a piece of cake - but 99% of the time this is not the case. Besides, most of the time the demo requires quite a bit of additional coding/content made and vetted. This is especially the case for large titles.
With console/multiplatform titles all you wrote falls to pieces immediately regardless of what title we're talking about because studios have to go through a rigorous certification process with anything they want to release on consoles, including demos, which means considerably more manpower is needed than just "1 guy 2 testers". Trust me, i know what i'm talking about.
FACT 1: most game projects never hit milestones on time and generally shit on timetables and initial planning due to lots of unforeseen issues happening. Games are a very complex piece of software. This means that they also usually go over initial budget assumptions - which ends with pissed off/scared shitless people allocating more funds or the entire team not getting paid until the agreed upon milestone is reached.
FACT 2: Many game projects never come into fruition because they miss the milestones repeatedly, go over budget and are eventually axed, even 'far' into development.
FACT 3: Depending on the game genre, target platform(s) and numerous other factors deciding to release a demo version of your title and thus potentially running into budgeting/timekeeping issues due to considerable resources that need be dedicated to it makes Fact 1 and Fact 2 much more likely to describe your project.
So there you have it.
Let me give you an example. A studio plans to release a demo of its multiplatform triple A title alongside the full game or before the full game's release.
1) Decide which parts of content are the most likely to entice players to buy the game.
2) Take parts of content that you want in the demo and modify them: they need to work fine even though the transitions are different, content and scripting are modified (fe you access an area from a different point than you did before, or something is blocked off etc).
3) Since the demo is to be released alongside or before the release of the full title, it needs to adapt to content/design changes of the full title; you must start developing the demo early and keep developing until the full title's content/design is preferably set in stone or at least highly unlikely to undergo major changes.
4) Your multiplatform title supports multiple languages so all the demo-specific strings like "HEY YO BUY THE FULL GAME WHEN ITS OUT" etc need to be localised and vetted; this takes more time and resources than you'd think. It doesn't work in a way that there's a single dude who knows a language and translates it before going to bed on sunday night. If your demo ends with a couple of screenshots of the full title with some text overlaid, the localisation guys need to translate it, then send it to the art team who prepare different versions, then it needs vetting by the publishing team and marketing etc etc.
5) Ensure that multiple features are completely disabled, especially those that are required to be disabled by the target platforms (Xbox Achievements/PS Trophies are an example)
6) Test thoroughly that all the departures from the original code that you've made haven't made the title unstable.
6a) Develop the demo so that it becomes stable because the original code you started working with at the beginning of the demo's development was an unstable mess that crashed if you sneezed at it and most of the fixes going into the full title are likely not to be applicable to the demo anymore by the time they arrive, or they would arrive too late to be of use, or implementing them would require lots of vetting work to see if there aren't any knock-off effects.
7) Ensure that the demo is actually enjoyable to play despite being a 15 minute romp through a tiny part of your game
8) Devote marketing resources to promote the demo.
... and these points are just the tip of the iceberg. There's much, much more that can come up. I've seen demos consuming a third of the dev team and lots of other resources for months
and most of their work on the demo does not push the full title forward meaning that the risks you're taking increase. This can, of course, be avoided with good planning, but game development is an incredibly haphazard enterprise and you can pretty much never count on your awesome plan to go smoothly.
Let me just remind you that most studios aren't Blizzard and they can't just take ages redesigning, tweaking, starting from scratch, and picking their nose. At some point someone's going to get incredibly pissed off and that can mean you and everyone around you losing your jobs.