I know people that work with assembler (not intel). They have build an extensive macro library so they can use it almost as if it is a high level language.
To create something lika a macro library, start simple. By grouping often used constructions in a single macro. Eventually wou will be able to create more complex functionality.
Not really the answer to your question, but In many real world scenarios, applications are written in a Higher language using the idioms common to that language, and only use a bit of assembly language where performance or hardware needs require. This is probably the only sensible approach for real projects, because assembly language just isn't as productive as other languages, in terms of getting the computer to do more for each hour spent programming it.
That being said, All of the tools and techniques for managing a project in any other language apply equally to assembly language. Source Control, TDD, Project specifications, meaningful names for identifiers, Separation of concerns, object oriented design patterns (you can have object oriented design without an object oriented language) all apply equally to assembly language as it does to C# or PHP
I always did just like is done in high-level languages. Write it in modules that are linked together to form the runtime.
The only modern project entirely written in assembly that I know if is FASM (my favorite assembler).
Some assemblers support high-level constructs, and if the macro engine is good, you can write your own. I personally find this useless; if I want high-level constructs and to understand what I do, I use C or C++. (I don't think they are good languages for managing big projects, though).
I just use assembly when needed, or for learning.
If you want to write a project in assembly, keep in mind that:
Here is a white paper by Peter Langston describing the tools and reasoning they used for writing Ballblazer and Rescue from Fractalus, which covers the organization etc.
Large scale assembly programmes are managed just like any other programme - well partitioned functional blocks with clear interfaces. Since you are working in assembly, your interfaces will be limited to things on the register file or stack. It is ultimately about having a good design plan ahead of actually implementation. You need to be crystal clear about what to write and how to write it.
That being said, if you like assembly, there is another way to be able to indulge in your passion without actually writing assembly code - you can write in C or C++ and see how code compiles to assembly. Then, write the same thing in a different way and understand how that changes the assembly. As a result, you will soon be able to think like a compiler and write highly optimal code.
Either way, knowing how things work in assembly will ultimately make you a better programmer.
Macros, functions, and libraries. It takes years to develop your own from scratch, so search for x86 assembler resources and lean on others - there are many people still doing active assembly development for the PC.
One active member of the assembly community is Steve Gibson, he has a whole bunch of links to good resources for assembly programming here:
On top of what has already been mentioned, I should mention literate programming; I wrote an application that was on the order of 20KLOC of ARM assembly (not huge, but not insignificant, either), and I found structuring the code with noweb to be extremely helpful.
This allowed me to break the code into small conceptual pieces, even when several pieces actually had to be combined together/unrolled/et cetera for performance reasons. It also made it much easier for other programmers to understand what I had written, particularly the reasons why I made certain subtle decisions (for example, deciding which operand should go first in a multiply based on expected size of the operands).