Like I said...this is the wrong sort of question.
It's sort of like if someone were to ask, "So, with Microsoft Word...can you write in screenplay format?" Microsoft Word has some templates built into it, but the program Microsoft Word itself is the program that handles things like representing characters on the screen, line spacing, font selection, font size, justification, etc etc etc. The answer to "Can you write in screenplay format" with Microsoft Word is a hard question to answer. Sure...you CAN write in screenplay format, with the proper use of the things that Microsoft Word does.
NESmaker is the tool that handles the things. The engine underneath is the variable here, and this will updated and changed and optimized probably for years to come, by us and other members of the community. "Can NESmaker do scrolling?" is sort of like asking "Can Microsoft Word write in screenplay format?". If you manipulate it correctly, sure. Will there be a single button that suddenly puts it into "scrolling mode"? That's too broad a concept to definitively answer.
The idea that "Well, I KNOW NES games could do things, because look at xyz game, it did this sort of thing." Yes, that's true, however that engine was written specifically to do all of those particular things. The default engine and the data organization underneath NESmaker is vanilla, meant to be able to easily modified into as many potential forms as possible. It would be much easier (not easy, mind you...but easier) to, say, create a standard RPG scrolling if we made it so each collision byte only had to be 2 bits worth of data (4 possibilities), but obviously that doesn't work for other types of games. Our main functionality has to be sort of the middle of the road, to be built upon.
Consider HUD development, for instance. It is SUPER easy for us to create a hud that functions just like the HUD in Super Mario Brothers. It's also super easy for us to create a hud that functions just like the HUD in Legend of Zelda. However, these are so dramatically different that what we have to do is create a central code base that can be manipulated through a front end to approximate both. The tool's job is not to make one that functions like Mario's OR Zelda's, but instead to give you access to components...draw a word here, draw a variable there, draw an image dependent on a variable over there, draw it at the top, or at the bottom, change the background color to match the level, or change the background color to black, etc etc etc. And then you take all the options and construct a thing out of all of that that fit's YOUR game's needs and visions.
I hope that we have a scrolling engine that supports basic horizontal (or vertical) scrolling natively by release. If not, I'm sure it would come in the months that follow soon thereafter, but that's no surprise. As soon as we started hitting stretch goals, each goal might take longer than the official release of the tool. But the main point is that people will be able to start getting acclimated in August, start snapping things together and seeing them on cartridge in a way they never have been able to before. Adding new ASM code to the back side of things will be a constant thing for us and any other developer who chooses to dig into the code. And trust me - learning to code in an environment where 90% of the backbone is already set up is MUCH easier than building from scratch.