Ultimately at runtime the files need to be copied up into the main web in order to work. The hello world examples use inline code with no code behind and therefore no compiled dll. If using this approach its ok to put the files in a custom folder within the main web project, but I would not add them to the project itself, ie I would not include them in the mojoPortal.Web.csproj file. I don't generally use inline code in my own work, that is just the easiest way for new developers without much ASP.NET knowledge to get started so I did it that way on the hello world examples to make it easy for people to get started. It works by just dropping in the files nothing to compile so its easier and lowers the entry point barriers for new developers.
For more advanced developers I recommend you organise your projects the same way I do. If you download the mojoportal source code and study the solution structure you will see that all the features are in a set of projects separate from the core and you can structure your projects them same way.
Most of the features are in the mojoPortal.Features.UI, mojoPortal.Features.Business, and mojoPortal.Features.Data* projects. They all compile into dlls. The mojoPortal.Features.UI project is a web project but you never run it directly. It has post build events that copy its dlls and .aspx and .ascx and .resx files up to the correct locations under the main mojoPortal.Web (aka Web folder) project. If you right click the mojoPortal.Features.UI project node and choose Properties you can see how to make a post build event for your own projects.
You do need to be careful that your post build doesn't accidently overwrite needed files in mojoportal. So, yes you do add files on disk but not to the projects and be careful in naming of folders and files to avoid clashes with existing files and folders. There are some folders that you will name the same but not files. There are conventions for where to put files for Setup, Help, Message Tamplates, resource files etc. You can even use the installation and upgrade sysetm to run your install and upgrade scripts and configure you feature automatically instead of via Administration pages. Study how this is done for mojoPortal.Features.UI to learn where files should go.
The ideas is for your custom features to live in your own custom projects and get copied up to the main project the same way we do with existing features. You can study the code for existing features and get lots of useful fragments for your own features butbest to avoid making changes directly on mojoportal code and keep all your custom stuff in your own external projects. I recommend getting the mojoportal cod from svn trunk and you can do svn update, rebuild solution visit /Setup/Default.aspx to get up to date on the latest version at any time. Its also good to subscribe to svh commit notifications so you can get emails and see what changes are happening in mojoportal code.
Hope it helps,