The way this is usually done in MFC is to define a dialog template in the resource editor (as you've done), then in C++ derive a class from CDialog and associate it with the dialog template (which it sounds like you've done - it's not entirely clear).
What actually associates the two is the constructor for your CDialog code. If you look at dialog related code auto-generated by the MFC class wizard, you'll see in the constructor implementation something like this:
CMyDlg::CMyDlg(CWnd* pParent /*=NULL*/) : CDialog(CMyDlg::IDD, pParent)
where CMyDlg::IDD is defined as an enumeration with a value of your new dialog template's identifier. It's this that makes it all happen, not the declaration of the enum. You could modify it to
CMyDlg::CMyDlg(CWnd* pParent /*=NULL*/) : CDialog(IDD_NEW_DIALOG, pParent)
and it will still work (assuming IDD_NEW_DIALOG is the template id of your dialog in the resources), as all that's happening is the dialog id is being passed into the constructor.
In general, it's always worth remembering that, despite initial appearances, MFC does not bind to Windows through bits of compiler magic - it's all done with C++ and a few macros.
EDIT: DIALOGEX and DIALOG declare slightly difference dialog resource formats that Windows understands: the former is newer than the latter. However both have been around since at least Windows 95, so it's not a very significant distinction.