After doing some more research, I've found:

• Imports ARE hoisted! according to the spec of ModuleDeclarationInstantiation
• ALL the dependent Modules will be loaded before running any code.

This code will have no errors, and will work:

localFunc();

import {myFunc1} from 'mymodule';

function localFunc() { // localFunc is hoisted
    myFunc1();
}

It will be a SyntaxError. According to this part of specification:

Module :
   ModuleBody

ModuleBody :
    ModuleItemList

ModuleItemList :
    ModuleItem
    ModuleItemList ModuleItem

ModuleItem :
    ImportDeclaration
    ExportDeclaration
    StatementListItem

It means that module can contain only ImportDeclaration's, ExportDeclaration's or StatementListItem's. According to this StatementListItem could not contain ImportDeclaration nor ExportDeclaration.

import myFunc1 from 'externalModule1'; 

is an import declaration, while:

if (Math.random()>0.5) {
    import myFunc2 from 'externalModule2';
}

is a statement. So your code will result to a syntax error.

What about "will they all be loaded before running the code?". This part of specification contain next sentence:

NOTE: Before instantiating a module, all of the modules it requested must be available.

So, yeah. They will all be loaded before running the code.

ES6 specification is a subject to change but this draft is explicit:

The static variable resolution and linking pass checks for conflicts in imported variable names. If there is a conflict between two imported names, or an imported name and another local binding, then it is a compile-time error.

And trying to import at runtime is doubtful idea, not only in ES6. Also from the draft:

Compilation resolves and validates all variable definitions and references. Linking also happens at compile-time; linking resolves and validates all module imports and exports.

You can see that Babel's ES6 implementation isn't too happy with it.